Capture before changing
Record current URLs, content, metadata, media, integrations, access, and performance context before the old system becomes difficult to inspect.
Migration planning resource
A website migration checklist for content, URLs, and a controlled release.
Document what exists, decide where every important asset will go, assign responsibility, and define the evidence required before the replacement website becomes the public system.
Migration safeguards
Control the move before improving the destination.
The migration plan protects useful assets and exposes unresolved responsibility. Visual redesign decisions remain within the redesign service rather than being repeated here.Give every route one outcome
Keep, revise, merge, redirect, retire, or hold each important route and document the target, canonical, indexation, and internal-link treatment.
Separate switching from proving
A successful deployment still needs production verification, exception handling, rollback authority, early monitoring, and an agreed support boundary.
Migration control register
Six workstreams keep the migration reviewable.
Each workstream records the source state, the decision required before implementation, the production evidence needed after release, and the primary responsibility owner.| Workstream | Capture before change | Decision before migration | Production evidence | Primary owner |
|---|---|---|---|---|
| contentContent and proof | Pages, copy, testimonials, files, forms, structured content, approvals, and content ownership. | Retain, revise, merge, replace, or retire each asset; confirm the destination format and approval owner. | Approved content appears at the intended destination with working links, media, downloads, and required disclosures. | Shared |
| urlsURLs and redirects | Current crawlable URLs, campaign paths, documents, backlinks where available, canonicals, and status behavior. | Keep or change each route; define one-hop permanent redirects, destination status, canonical, and internal-link updates. | Source and target map passes; important routes resolve once, redirect chains are avoided, and expected 404 behavior remains available. | Simpleweb |
| searchMetadata and search signals | Titles, descriptions, headings, canonicals, indexation rules, structured data, internal links, robots, and sitemap membership. | Assign keyword and page ownership, merge conflicting signals, and approve the final canonical and indexation treatment. | Rendered metadata, schema, canonicals, links, robots directives, and sitemap output match the approved production routes. | Simpleweb |
| mediaMedia and public files | Image and document paths, dimensions, alt text, usage, rights, download links, icons, manifests, and social assets. | Migrate, compress, replace, rename, or retire assets; document path rules and any rights or approval dependency. | No priority media or public file is broken, dimensions remain stable, and approved alternatives and loading behavior are present. | Shared |
| systemsAnalytics and integrations | Tags, events, forms, CRM or email routes, APIs, consent behavior, production IDs, fields, credentials, and response owners. | Approve each connected system, data path, failure state, consent requirement, access owner, and production responsibility. | Scoped submissions, events, notifications, integrations, access, and failure behavior are tested with approved production inputs. | Client |
| releaseHosting, DNS, and rollback | Hosting, domains, DNS, certificates, environments, cache, backups, credentials, release access, and current recovery options. | Name the release owner, launch window, content freeze, DNS owner, rollback trigger, recovery path, and monitoring period. | Production domain, HTTPS, redirects, cache, release version, recovery path, access, and early monitoring checks are documented. | Hosting |
Controlled sequence
Move from evidence to production in four stages.
The exact tools and release path depend on the current and future platforms, but the decision order remains useful across CMS, static, hybrid, and custom builds.Inventory
Capture important pages, routes, content, files, metadata, integrations, access, environments, and ownership before implementation changes begin.
Output: Current-system evidence inventoryMap
Approve destinations, retention decisions, redirect behavior, content ownership, metadata treatment, integration requirements, and release dependencies.
Output: Migration and responsibility mapMigrate
Move approved assets and signals into the new system in reviewable increments, then test routes, content, media, metadata, and scoped connections.
Output: Migration-ready release candidateRelease and observe
Authorize the production switch, verify the live environment, record exceptions, monitor priority routes and systems, and use rollback when the approved trigger is met.
Output: Production verification and handoff
Migration questions
Clarify responsibility before the production move.
No. Redesign changes the website's structure, interface, or messaging. Migration controls how approved content, URLs, metadata, media, integrations, and release responsibilities move from the current system to the new one. A project may include both.
No. Auditing important routes and signals, mapping redirects, retaining useful content, checking canonicals, and monitoring production can reduce avoidable migration risk. Search performance still depends on systems and conditions outside any agency's control.
No universal zero-downtime promise is appropriate. Availability depends on hosting, DNS, certificates, caching, deployment architecture, third-party services, access, and the approved release method. The plan should define expected behavior, recovery, and authority.
Requirements may include the current CMS or repository, hosting, domain and DNS, analytics, tag management, forms or CRM, media storage, backups, search tools, and relevant credentials. Access should be limited, approved, and assigned to an owner.
Before the production switch. Important current URLs need an approved destination or retirement decision early enough for implementation, internal-link updates, QA, stakeholder review, and rollback planning.
Migration scope