A platform move looks simple from the outside: the new thing is better, so move to the new thing. What makes it risky is that the old system is load bearing while the new one is being built, and the business does not pause for the transition.
Separate what moves from what stays
A website migration usually involves several independent pieces: the site itself, the domain registration, DNS, email routing, and any connected systems like booking or payments. People treat these as one object. They are not, and the distinction is what gives you options when something blocks.
A useful example from a recent engagement: JaVa Heritage, a property management company, had a new Wix site ready to launch. The domain was still at its previous registrar and an ICANN sixty day transfer lock made moving it impossible. The obvious read was to wait two months.
But registration and DNS are separate concerns. We kept the domain registered where it was and pointed its DNS at the new site instead. The new website went live on the original schedule, and the transfer completed later on its own timeline. Nothing about the launch depended on winning an argument with a registrar policy.
That is the general lesson. When one piece is blocked, ask which of the other pieces can move independently.
When the platform is going away, the data is the project
Not every migration is chosen. Sometimes a vendor sunsets a product and the timeline belongs to them.
The American Collegiate Baseball League faced that. One of the largest nonprofit collegiate leagues for young men pursuing professional careers, it kept years of records, rosters, statistics and league history on PrestoSports, and that platform was ending. The website was the visible concern. The archive was the real one. A league of that age runs on its own record, and losing it would have meant losing something that could not be rebuilt from memory.
So the work started with the data: getting it off the old platform intact and onto the new one, then building the site around it. The site was the deliverable. The history was the point.
That order matters generally. When a platform is closing, extract and verify your data first, before design conversations begin. Vendor export tools vary in quality and some omit exactly the historical records that matter most. Check what came out against what should be there while you still have access to the original.
Leave the client able to run it
A migration that ends with an organization dependent on whoever built the new thing has replaced one constraint with another. That is a particular risk for nonprofits, where budgets are tight and the person maintaining the site is often a volunteer with other responsibilities.
For the league, part of the engagement was training their people to maintain the site themselves, so routine updates never require a call to an outside party. It is worth building into scope deliberately, because it rarely happens by accident.
Preserve what search engines already trust
The most common expensive migration mistake is losing accumulated search equity. If a page ranks today and its address changes without a redirect, that ranking goes away and takes months to rebuild.
Before moving, inventory the pages that currently receive traffic. Map each old address to its new one. Redirect them permanently. Keep page titles and headings substantially intact on pages that already perform, because a redesign is not a reason to rewrite copy that is working.
Sequence to keep a working state
Build the new site fully before pointing anything at it. Verify it on a temporary address. Only then change DNS. Handle email separately and verify it independently, since email and website records are unrelated and breaking one while fixing the other is a common and avoidable outage.
Do the cutover when you can watch it, not at the end of a Friday.
Know what you are actually buying
Migration is worth doing when the current platform limits something the business needs: speed, control, cost, or the ability to change things without help. It is not worth doing because a platform is unfashionable. Those are different justifications and only one of them survives contact with the invoice.