The order a migrate to WordPress project has to run in
Most migration damage comes from doing these in the wrong order. In short, a migrate to WordPress project is an addressing exercise with a content step in the middle.
- Inventory first. We list every address on the current site before anyone builds anything. That list feeds the redirect map, and without it the map is guesswork.
- Decide the new structure. We choose the new addresses deliberately. A theme default should not decide them for you.
- Build and move the content. The part most people think is the whole job.
- Write the redirects. Every old address points at its closest real equivalent, never at the homepage.
- Rebuild what does not travel. Forms, integrations, analytics, and the search settings on every page.
- Verify, then switch off. The old platform stays reachable until the new one works. That order is reversible. The other one is not.
Which platform you are coming from changes the job
The work differs by direction, so the differences are worth knowing before you take a quote seriously.
From a website builder
Wix gives you no meaningful export. So the move becomes a rebuild rather than a transfer, and the cost tracks labour instead of page count. Squarespace does export, but the export carries content and not design. Both platforms hold your redirects on the old subscription. Because of that, sequencing matters as much as the build. Our guide to what a builder migration actually costs covers the full price ladder and the redirect trap. We run both moves as fixed-scope work: Wix to WordPress and Squarespace to WordPress.
From another CMS
Joomla and Drupal both export, and import tools exist for both. So the content moves reliably. The risk sits elsewhere. URL patterns differ sharply between platforms, which makes the redirect map larger than people expect. Sites on an unsupported release carry a second problem, because staying put costs something too. We handle both platforms directly: Joomla to WordPress and Drupal to WordPress.
From a store platform
Commerce migrations add orders, customers and tax configuration to the list. The checkout also needs a full test with real money paths before launch. The most common route is Magento to WooCommerce. If you land on WooCommerce, our WooCommerce support covers the work afterwards.
What we take on, and what we do not
The same published limits that govern our repair work apply here. In short, we take the migration when WordPress is the destination and the job is a site rather than an application.
We do not move sites away from WordPress. We do not run the platforms on the other side, so we would be guessing. We also flag rebuilds dressed up as migrations before you commit, because sometimes a rebuild is the honest answer. Finally, we decline when the content lives inside a platform that cannot export it and nobody can reach it. No provider can move what nobody can read.
Our full service scope sets out where the line sits, and how it works describes the diagnosis-first process behind every engagement.
When not to migrate at all
Sometimes the right recommendation is to stay. We would rather say so before you spend the money than after.
Consider a small site where nothing blocks you and nobody wants to own maintenance. A hosted builder is already doing a job that WordPress would hand back to you. Equally, if the site keeps breaking, the real finding is usually maintenance rather than platform. That problem travels with you. We work through that case in deciding whether to leave WordPress, which argues the same point in the opposite direction.
What you get, and what happens next
We confirm scope and price in writing before implementation starts. That includes the exclusions and the rules for handling changes.
A migration engagement gives you three things you keep. A redirect map. A verified list of what moved. A record of what we rebuilt and where it now points.
Afterwards the site is yours to maintain, and that obligation starts on day one. So most people settle it up front with ongoing WordPress care rather than discovering it at the first failed update.
Want to know what your own migration involves? Start a diagnosis. You get the risks, the address plan and an honest answer in writing. That includes the times we tell you your current setup is fine. Read the migration risk guide first if you are comparing providers, because it tells you which questions to ask.