The most stressful migration story I keep hearing from SMBs follows the same shape: they decide to migrate platforms (hosting, e-commerce, CRM, email — the specifics vary). They schedule a "cutover weekend" where everything will move at once. They work through Saturday night. By Sunday afternoon, half of it is broken, the other half is in a state nobody fully understands, and Monday morning customers are complaining.
This pattern is preventable. Migrations don't have to be high-risk weekend events. The professional approach is phased — parallel run both old and new systems for a period, gradually shift traffic, decommission the old system only after the new one has fully proven itself. Done right, customers don't notice the migration is happening. Done wrong, you've burned trust and dollars in a way that takes months to recover from.
This article is the general framework. It applies to migrations of website hosting, e-commerce platforms, CRMs, email systems, payment processors, and most other categories. The mechanics differ but the playbook is the same.
Why "cutover weekend" migrations fail
Three structural problems with the rip-and-replace approach:
1. Everything must work at once. A traditional cutover means flipping a switch and having all components — database, application code, integrations, DNS, third-party services, customer data — work simultaneously the moment the switch is flipped. Each component has a probability of failure. Multiplying probabilities, the chance of something failing is much higher than the chance of any individual thing failing.
2. Discovery happens at the worst time. A cutover migration uncovers problems during the cutover. You discover the missing field, the unsupported feature, the integration that doesn't carry over — at 11pm Saturday night, when the team is exhausted and the rollback option is "lose everything."
3. Rollback is hard. Once cutover starts and customers are touching the new system, rollback becomes increasingly difficult. New orders placed on the new platform. New customer registrations. New data. Each minute makes rollback more expensive. By the time you realize there's a real problem, rollback might mean throwing away the customer data created during the broken cutover.
The phased approach inverts all three. Failures are caught one at a time, in advance, when fixing them is cheap. Rollback is always available because you haven't burned the bridges yet. Discovery happens during normal hours when help is available.
The five-phase migration playbook
The general framework. Specific tools and tactics differ by category, but the phases are the same.
Phase 1: Inventory and design (Week 1–2)
Before any migration work, document:
- What's currently running (every component, integration, customisation, custom feature)
- What needs to migrate (the actual data and configuration)
- What can be left behind (temporary configurations, deprecated features, dead code)
- What the destination platform supports (and where it differs from current)
- What needs custom work to bridge gaps
Most cutover failures are inventory failures. The thing that broke at 2am was a thing nobody documented or thought about until it broke. Spending two weeks on inventory eliminates this category of disaster.
The output: a written migration plan. Not a project management chart — a plain-language document that says "here's everything that's currently happening, here's what needs to happen on the new platform, here are the gaps and how we'll close them."
Phase 2: Build the new system in parallel (Week 2–6)
Stand up the new platform alongside the old one. Both are operational, but only the old one is serving customers. The new one is a mirror that you're testing against.
Specifics by migration type:
Hosting migration: new hosting environment running the same application code, with a copy of recent production data. Old hosting still serves customers via DNS.
Platform migration (Shopify ↔ custom, WP ↔ custom): new platform built and configured, with imported data, tested with team members. Old platform still serves customers.
CRM migration: new CRM populated with imported data, integrations built and tested. Sales team continues using old CRM for daily work.
Email migration: new email service configured, all sending domains authenticated. Old email service still handling all production traffic.
This phase ends when the new system is capable of replacing the old one — but the old one is still doing the work.
Phase 3: Parallel run with synthetic traffic (Week 6–8)
Send test traffic to the new system. Verify it produces the same results as the old system.
Specific tests:
- Run a complete order flow on the new e-commerce platform. Place an order. Verify everything from inventory through invoicing through fulfilment.
- Send a test campaign on the new email platform. Verify SPF/DKIM authentication, deliverability, tracking links.
- Run a sales workflow on the new CRM. Create a lead, work through the pipeline, mark as won. Verify reporting captures it correctly.
- Run automated tests against the new hosting environment. Compare response times, error rates, behaviour.
Bugs found here are cheap to fix. The new system isn't yet doing real work; you can break it freely while testing. By the end of this phase, you have high confidence the new system works.
Phase 4: Gradual traffic shift (Week 8–10)
Start sending real traffic to the new system, but only a percentage at first.
Specific approaches by migration type:
Hosting: use DNS or a load balancer to send 10% of traffic to the new server. Monitor for issues. If clean, increase to 25%, then 50%, then 100% over a week.
Platform: start by routing new customers to the new platform while existing customers stay on the old. Or route specific product categories. Or specific countries. Whichever lets you start small and scale up.
CRM: pick one team member to use the new CRM exclusively. Watch how they work for a week. Address issues. Then move two more team members. Continue until everyone's migrated.
Email: start sending one email category from the new service (e.g., transactional only). Monitor deliverability. If clean, add another category. Continue until everything's moved.
This phase is designed so problems show up at small scale before they affect everyone. If something is wrong, you find out at 10% traffic, not 100%, and the fix is bounded.
Phase 5: Decommission the old system (Week 10+)
Only after the new system has carried 100% of traffic for at least a week, with no issues, do you decommission the old system. Even then, leave it accessible (in read-only mode) for 30 days in case you need to reference data or recover something.
After 30 days of stable operation, fully decommission. Cancel old subscriptions, archive old data, remove old DNS records. The migration is complete.
Common SMB migration types and their specifics
Hosting migration (most common)
Old hosting → new hosting. Same application code, different server.
Phased approach:
- Stand up new hosting environment with current application code
- Sync database from old to new on a delay (e.g., daily snapshot)
- Test new environment with team-only traffic
- Switch DNS to send 10% of traffic to new (using weighted DNS or a load balancer)
- Increase percentage over a week
- Switch database master to new environment (this is the trickiest step)
- Decommission old hosting after 30 days
Total time: 2–4 weeks for an SMB.
E-commerce platform migration
Shopify → custom, or WooCommerce → Shopify, or similar.
Phased approach:
- Build new platform alongside old
- Import historical orders, customers, products
- Test with team accounts
- Set up redirects from old URLs to new (critical for SEO)
- Route new customer traffic to new platform; existing customers stay on old
- Migrate existing customers in batches (export/import customer accounts and password resets)
- Switch full traffic when both platforms have feature parity
- Run both platforms for 30 days, then decommission old
Total time: 6–12 weeks. SEO preservation is critical and adds work — see the WordPress to Custom Stack Migration service page for the specific SEO disciplines that prevent ranking loss.
Email service migration
Mailchimp → ConvertKit, or G Suite → Microsoft 365, or similar.
Phased approach:
- Configure new service with proper SPF/DKIM/DMARC (see the Email Deliverability article)
- Warm up new sending domain over 4 weeks (low volume gradually increasing)
- Move transactional email first (lower stakes than marketing)
- Move marketing email second, in batches
- Run both services for one full email cycle
- Decommission old service
Total time: 4–8 weeks. Don't rush email migration — domain reputation takes weeks to build and is hard to recover if you damage it.
CRM migration
Pipedrive → HubSpot, or similar.
Phased approach:
- Map fields between old and new (this is harder than expected)
- Import contacts and historical activity
- Configure pipelines and automations
- Pilot with one or two team members for 2 weeks
- Roll out to remaining team members in batches
- Run both CRMs in read-only-old mode for 30 days
- Decommission
Total time: 4–6 weeks.
Payment processor migration
Stripe → Paddle, or PayPal → Stripe, or similar. The trickiest category.
Phased approach:
- Set up new processor in test mode
- Configure all webhooks and integrations
- Test thoroughly with test transactions
- Move new customer signups to new processor; existing subscriptions stay on old
- Gradually migrate existing subscriptions (this is the hardest part — requires customer notification, sometimes re-authorisation)
- Run both for as long as legacy subscriptions exist
- Cancel old processor when no active subscriptions remain
Total time: 3–12 months depending on subscription terms. Don't rush payment migrations — financial relationships are the most fragile.
What to negotiate with your new vendor
Most SMBs don't negotiate with new vendors during migration. They should. Specific things to ask for:
- Free trial or first month to validate the platform actually works for your use case
- White-glove migration support from the vendor's team (often free for new mid-tier or higher accounts)
- Performance and uptime SLA that matches your business requirements
- Data export commitment in writing — if you ever leave, what data can you take and how
- Pricing lock for 12–24 months so the vendor doesn't raise prices during a critical period
These are normal asks. Vendors expect them. Smaller vendors will negotiate readily; larger ones less so but it's still worth asking.
What to negotiate with your old vendor
Don't burn bridges. Things to negotiate when leaving:
- Extended access during migration (sometimes free for 30–60 days, sometimes for a small fee)
- Read-only access after cancellation for a period (so you can reference historical data)
- Data export in usable format (CSV/JSON, not PDF)
- Refund of unused term if you've prepaid
Most SMBs just cancel without negotiating. Many vendors will offer concessions if asked, especially for accounts in good standing.
When to hire help
Migrations benefit from someone who's done the specific category before:
- Large or complex migrations (multiple integrations, lots of historical data, regulated data)
- Migrations with hard external deadlines (you must be off old platform by date X)
- Migrations where the rollback path is unclear
- First migration on a particular platform (the second one is much easier)
Migration support is the kind of work that pays for itself in problems-not-encountered. The Lead Steer monthly retainer covers migration work, or specific service pages cover specific migration types (WordPress migration).
What to do next
The companion articles cover related L3 work:
- Why Your AWS Bill Keeps Going Up — relevant if migration is a cost decision
- The Backup You Have But Probably Can't Restore — verify backups before migrating
- No-Code vs Code: When to Use Bubble vs When to Hire — covers the phased migration approach for no-code → code specifically
---
Part of the Level 3 Tech Support pillar guide.