Answer in brief
A migration is four separate jobs under one name, and they fail independently. This covers the inventory, the map of old and new addresses, redirects, forms and integrations, the cutover window, and the rollback plan you write before you need it.
What a migration actually moves
Moving a site to a new platform is four separate jobs wearing one name: the addresses people and search engines already know, the content and media, the data held in forms and integrations, and the infrastructure the site runs on. They fail independently, and each needs its own plan.
Most of the damage from a bad migration is not visible on launch day. The new site looks right, so it is signed off; the losses show up two weeks later as pages that no longer resolve, a form that stopped delivering, and analytics that start from zero with no way to compare.
The way to avoid that is unglamorous. Write down what exists before you change anything, decide where each item goes, and check the list after the switch rather than trusting the impression that everything works.
This article walks that list in order, ends with the rollback plan you write before you need it, and names where a migration sits in packages that carry fixed prices — including the one that explicitly does not cover this work.
The inventory: write down what exists before anything changes
Start with a full list of the current site's addresses. Export it from the sitemap, from the server logs, from the analytics platform and from a crawl of the site, then merge the four. Any one source alone will miss pages, and the pages it misses tend to be old ones that still receive visits.
Add what each address is: a page, a file, a redirect that already exists, or something that returns an error today. Addresses already broken before the move are worth knowing about, because after the move every fault looks like the migration's fault.
Inventory the media separately — images, documents, video files — with the folder each lives in. Media paths change more often than page paths during a platform move, and a document that stops resolving is harder to notice than a missing page.
Finally, list the integrations: what sends mail, what receives form submissions, what reads or writes data, what loads a script into the page. This list is the one most often kept in someone's head, which is exactly why it belongs in a file.
The URL map: one old address to one new address
The core artefact of a migration is a two-column table: every old address on the left, the address that replaces it on the right. It is tedious to build and it is the single thing that decides whether the move is invisible to visitors or not.
Every row needs a decision, and there are only three: the page continues at a new address, the page merges into another page, or the page is retired. Retiring is a legitimate choice; leaving a row blank is not, because blank rows become error pages.
Resist the urge to send everything you are unsure about to the home page. A visitor who clicked a specific article and lands on a home page has been given a dead end with a friendly face, and search engines treat that pattern as a soft failure rather than a move.
Keep the map as a file in the repository, not as a spreadsheet in someone's mailbox. It is the document you will re-read during the checks after the switch, and again in a year when somebody asks why an old address behaves the way it does.
Redirects, and what a redirect cannot repair
A permanent redirect tells a browser and a crawler that a page has moved for good. Implement the map as permanent redirects rather than temporary ones unless the move genuinely is temporary, because the two are treated differently and the difference is not cosmetic.
Chains are the quiet cost. An address that redirects to an address that redirects again works, but it is slower for every visitor and weaker as a signal. Flatten the chains so each old address points directly at its final destination.
Redirects do not repair links inside your own content. A page body that links to an old internal address will keep working through the redirect, but it is now paying for a hop it does not need. Rewrite internal links to their new targets as part of the move.
And a redirect does nothing about external links you do not control. That is the argument for keeping the old address structure wherever it is reasonable: every address you preserve is a link you never have to redirect, and one fewer thing that can be misconfigured.
Content and media: the part that is larger than it looks
Content rarely moves cleanly between platforms. Formatting is stored differently, embedded media is referenced differently, and fields that exist in one system have no home in the other. Budget time for reviewing what arrived, not only for moving it.
Check a sample properly rather than glancing at everything. Take a dozen pages of different types — a long article, a product entry, a page with a table, a page with an embedded video — and read them end to end on the new platform.
Media needs its own pass. Confirm the files transferred, that their addresses are covered by the map, and that alternative text survived the move. Alt text is frequently stored in a field that has no counterpart on the new platform and is silently dropped, which is both an accessibility regression and a content loss; the W3C's WCAG 2.2 quick reference is the practical standard to check against.
Take the opportunity to fix image weight while the files are moving anyway. MDN's performance documentation is a fair reference for what actually matters here, and a migration is the one moment when touching every image costs almost nothing extra.
Forms, integrations and the failures that stay quiet
A broken page announces itself. A broken form does not: it accepts the submission, thanks the visitor, and delivers the message nowhere. This is the failure mode that costs the most and is discovered the latest.
Test every form by sending a real submission and confirming it arrives at every destination it is supposed to reach — the inbox, the CRM, the notification channel. Test them again after the DNS change, because mail delivery in particular can behave differently once the domain moves.
List the third-party scripts the old site loaded and decide about each one deliberately. A migration is a reasonable moment to remove the ones nobody can name a purpose for; each one that stays is a request the page pays for on every visit.
Where data flows both ways — stock levels, orders, bookings — plan a period where you can verify both directions with real records before the old system is switched off. A one-way check confirms half of an integration and creates confidence in the other half without evidence.
Analytics: keeping the history readable after the move
Decide before the switch whether the new site reports into the same analytics property or a new one. Keeping the property preserves the history but mixes two different site structures in one dataset; starting fresh gives clean data and loses the comparison.
Whichever you choose, mark the date. An annotation on the day of the cutover is what stops a future reader from mistaking a platform change for a market change, and costs one minute to add.
Re-check that the events you rely on still fire. Form submissions, purchases, downloads, clicks on a phone number — these are usually implemented as page-specific code, and page-specific code is exactly what a platform move rewrites.
Expect the first days after a migration to look strange, and give the numbers time before drawing conclusions. Crawlers re-check a moved site at their own pace, and reacting to week-one figures usually produces changes that then have to be undone.
DNS, certificates and the cutover window
The switch itself is a DNS change: the domain stops pointing at the old server and starts pointing at the new one. Lower the record's time-to-live a day in advance so the change propagates quickly, and raise it again once the move has settled.
Have the certificate issued and verified on the new platform before the switch, not after. A site that resolves but throws a security warning is worse than a site that is briefly unavailable, because browsers make the warning loud and visitors read it as a compromise.
Do not move the mail records without checking them. Mail and web often share a domain and rarely share a provider, and a migration that carries the mail records along by accident takes down the address the business answers on.
Choose the window deliberately. The quietest hours for your audience, with the people who can act still awake, beats a technically convenient time when nobody is available to read the first checks.
Search visibility: what to expect and what to watch
A well-mapped migration usually produces a short unsettled period rather than a lasting drop, but the honest answer is that the size of the movement depends on how much of the address structure changed and how completely the map covers it.
Submit the new sitemap and keep the old one available for a while so crawlers can find the moved addresses. Watch the error reports rather than the ranking reports in the first two weeks: a rise in unreachable pages is actionable, a rank wobble usually is not.
Check that pages are not blocked by leftover instructions. Staging environments are commonly closed to crawlers, and a rule written to protect the staging site has followed more than one project into production and quietly removed it from search.
Keep the map in reach during this period. Almost every problem reported in the first month resolves to a row in it that was left blank, pointed at the wrong page, or written with a typo.
The rollback plan, written before you need it
Before the switch, write down how to go back: which DNS records to restore, how long the old environment stays available, who is allowed to make the call, and what condition would justify making it. Three sentences are enough, and they change how the day feels.
Keep the old site running and reachable in the background for a defined period after the move. It costs one more month of hosting and it is the difference between a bad day and a bad week.
Do not delete anything on cutover day. Databases, media folders, and the old configuration should survive the move by a period you have named in advance, because what is missing usually announces itself after the first full week of traffic.
Name the decision maker in the plan. Rollback decisions taken by a group, at speed, on incomplete information, are how a recoverable problem turns into two migrations instead of one.
Testing before the switch, checking after it
Before the switch, run the new site through the same checks you will run after: every template opens, forms submit, the search works, the pages load on a phone, the address structure matches the map. Doing this on the staging environment removes most of the surprises.
After the switch, run the map itself. Request every old address and record what it returns. This is a script, not an afternoon of clicking, and it converts the question of whether the migration worked into a list of rows that did not.
Check the pages that are easy to forget: legal pages, the pages linked only from a footer, files linked from an email campaign, and anything with an address that was hand-written rather than generated.
Then check it again a week later. Some failures only appear once caches expire and crawlers return, and a second pass over the same list is a cheap way to catch them while the context is still fresh.
Where a migration sits in the VITON13 packages
It is worth being direct about scope, because a migration is often quoted as though it were a small fix. Site Fix Pack is $70 and runs 1-2 working days for up to five agreed fixes, with a mobile and desktop check and a before/after list at handover and one round of revisions — and migrations are explicitly named as not included in it.
A move that produces a new site belongs with Launch Site at $380 over 3-5 working days, which covers a responsive build, core CMS or data wiring and deployment setup, with two rounds of revisions before launch; content and translations are supplied by you. Launch Site Express is $520 and delivers that same scope in a priority queue over 2 working days with daily builds, a launch checklist and a handover call, with one round of revisions after the first full build and content, photography and ongoing support excluded.
Where the move also changes what the product does — new features, new state and route logic, testing and hardening — Product Build is $880 over 2-3 weeks with two rounds of revisions per delivered feature, and native mobile apps and payment licensing sit outside it.
The weeks after a cutover are where Ongoing Dev Support earns its place: $290 per month on a monthly cycle with 30 days notice to stop, covering priority updates, a weekly release rhythm and technical maintenance, with the volume agreed at the start of each cycle and a new build or redesign scoped separately.
Practical checklist
- Build the address list from the sitemap, the server logs, analytics and a crawl, then merge all four.
- Write the old-address to new-address table and leave no row blank.
- Flatten redirect chains so every old address points straight at its final destination.
- Send a real submission through every form and verify each destination after the DNS change.
- Lower the DNS time-to-live a day ahead and issue the certificate before the switch.
- Write the rollback plan and the period the old environment stays reachable.
Questions and answers
Will the site lose rankings when it moves platform?
A well-mapped migration usually produces a short unsettled period rather than a lasting drop. The size of the movement depends on how much of the address structure changed and how completely the redirect map covers it, which is why the map is the main protection.
Is a migration covered by the small-fixes package?
No. Site Fix Pack is $70 over 1-2 working days for up to five agreed fixes, and migrations are explicitly named as not included. A move that produces a new site belongs with Launch Site at $380 over 3-5 working days, or Launch Site Express at $520 over 2 working days.
Can every old address just redirect to the home page?
Technically yes, and it is a poor decision. A visitor who clicked a specific article and lands on the home page has been given a dead end, and search engines read a bulk redirect to the home page as a soft failure rather than a move.
How long should the old site stay up after the switch?
Name the period in advance and delete nothing on cutover day. Databases, media folders and the old configuration should survive the move by that stated period, because what is missing usually announces itself after the first full week of traffic.
What breaks most quietly during a migration?
Forms and integrations. A form accepts the submission, thanks the visitor and delivers the message nowhere. Test every form with a real submission before and after the DNS change, and confirm it arrives at every destination — the inbox, the CRM and the notification channel.