.webp)
What to do in the 60 days before, during, and after the switch
Replacing your website is the single biggest go-to-market risk most marketing teams take. Done well, it ships pipeline. Done poorly, it tanks rankings, breaks lead routing, and burns six months of momentum your team has been compounding.
Most of the bad migration stories share the same root cause. The team optimised for the launch date and skipped the discipline that surrounds it. This is the playbook for doing it right — what to do before, during, and after the switch — based on what we’ve shipped for M13, Bigeye, Uniqode, and dozens of other teams who moved off legacy platforms without losing their SEO equity or their CMO’s confidence.
The fast version
A clean migration runs in three phases. Pre-launch auditing in the 60 days before (URL inventory, ranking baseline, redirect map, integration audit). Execution in the launch window itself (staging QA, DNS cutover, 301 activation, sitemap resubmission, real-time verification). Monitoring in the 30 days after (Search Console crawl review, ranking comparison, conversion delta, redirect cleanup). Skip any of the three and you’ll discover what broke in the wrong order — usually from a panicked CRO at 11pm.
The Hospital Transfer
Why the platform isn’t the risk — the gap between platforms is
A web migration is like transferring a patient between hospitals. The old hospital works. The new hospital works. Both have qualified staff, clean records, and proper equipment. The risk isn’t either facility — it’s the ambulance ride in between, and the handoff at the receiving door.
Most agencies sell you the new hospital. The teams that actually deliver successful migrations spend most of their planning energy on the transfer itself — the redirects, the data parity, the team handoff, the moment when the old systems shut down and the new ones come up. Get the transfer right and the destination platform is almost a footnote. Get it wrong and the best CMS in the world won’t save your rankings.
Phase 1: The 60-day pre-launch audit
The work that decides whether a migration goes smoothly happens before anyone touches the new platform. Six things to lock down:
URL inventory
Crawl every URL on the existing site. Not just the ones in the sitemap — every URL Google has ever indexed. Pull the data from Search Console (Pages report), Ahrefs or Semrush (Top Pages report), and a fresh Screaming Frog crawl. De-duplicate and tag each URL with: current traffic, current rank position for its primary keyword, current backlink count, and a target URL on the new site.
This list becomes your 301 redirect map. Pages with zero traffic and zero links can sometimes be merged or dropped. Pages with anything else need a direct, intentional redirect — not a sitewide fallback to the homepage, which is the most common mistake teams make on a first migration.
Ranking baseline
Lock in your current rankings for the top 100 keywords driving organic traffic. Use a rank tracker that captures a daily snapshot starting 30 days before launch. Without this baseline, you’ll have no way to tell whether post-launch ranking changes are migration damage or normal volatility.
Conversion tracking baseline
Document current conversion rates for every key path on the site — form submissions, demo requests, ebook downloads, free-trial signups. Capture the funnel data at the page level so you can compare apples to apples after launch. A 0.5% drop in homepage conversion on a high-traffic page is real revenue. You need to be able to see it.
Integration map
List every third-party tool talking to the current site. HubSpot forms, Calendly embeds, Intercom widget, Segment, GTM containers, ABM tools like RB2B or Clearbit, chatbots, video hosts, custom webhooks. Each one needs a tested integration on the new site before launch, not after. Forgetting one means leads silently routing to nowhere on Day 1.
Content inventory
Every page, every blog post, every PDF, every video. Decide before launch what carries over, what gets rewritten, what gets cut, and what gets archived with a 410 instead of a 301. Cutting low-value content is part of the migration, not a separate project — Google’s crawl budget gets allocated cleaner when you ship fewer pages of higher quality.
Redirect plan
Build the 301 map as a spreadsheet. Source URL in column A, destination URL in column B, notes in column C. Validate it before launch — for each row, check that the destination actually exists on the new site. The most common launch-day failure is redirecting traffic to a 404. Five hours of validation prevents weeks of rankings loss.
Phase 2: The execution window
Launch day isn’t one moment. It’s a structured sequence. The shorter you can make it, the less risk you carry.
Final staging QA
Walk every page on the staging URL. Test every form submission with a real address. Confirm every integration fires. Pull the staging site through Lighthouse and resolve any red flags before DNS cuts over. The discipline here is to fix on staging, never on production.
DNS cutover
Schedule the DNS change for low-traffic hours. Set the TTL on your DNS records to 5 minutes a full 24 hours before launch — otherwise propagation drags for hours and your team can’t tell whether a user is hitting the old or new site. Have both teams (old platform and new platform) on standby in a shared channel during the window.
301 redirect activation
Push the entire 301 map to the new platform at the moment of cutover, not piecemeal afterward. Webflow’s redirect interface accepts batched paths — paste the whole map, save, publish. Verify with a redirect tester (httpstatus.io is free) that a sample of 20 redirects across the map are firing correctly.
Sitemap resubmission
New sitemap submitted to Search Console within an hour of launch. Old sitemap (still pointing to legacy URLs) removed. This signals to Google that you’ve intentionally changed the URL set, and accelerates the re-crawl of the new structure.
Real-time verification
In the first hour post-launch, run through a 15-point verification checklist. Homepage loads. Top 5 traffic pages load with proper redirects. Forms submit and route to the CRM. Analytics fires. No 500 errors in server logs. A teammate testing as a logged-out user from a different IP confirms what you’re seeing. The first hour catches 80% of launch-day issues if you’re looking.
Phase 3: The 30-day post-launch monitoring window
The first 30 days post-launch is when migrations either prove themselves or unravel. Four things to watch:
- Search Console crawl health — monitor the Pages report daily for the first 14 days. Watch for sudden spikes in ‘Not found (404)’ or ‘Redirect error’ — these are missed entries in your 301 map. Fix them within 24 hours.
- Ranking comparison — your rank tracker should show a brief dip in the first 7–14 days followed by recovery. If a key term loses rank and stays down past day 21, something’s wrong — usually a redirect chain, a canonical mismatch, or content that didn’t carry over cleanly.
- Conversion delta — compare week-over-week conversion rates against your pre-launch baseline. A 10–20% temporary drop is normal as users adjust. A persistent 30%+ drop is a problem — usually a form integration that’s silently failing or a CTA that moved below the fold.
- Integration health — every Monday for 4 weeks, manually verify your top 3 integrations still work end-to-end. A test form submission, a test demo request, a test newsletter signup. The ones that break silently are the ones that cost real pipeline.
The objection your CFO will raise
“We can’t afford to risk our search rankings on a platform migration. Our current site works.”
Real concern, wrong frame. The risk isn’t the migration — it’s standing still while your CMS quietly costs you GTM velocity. Every campaign that gets stuck in a dev queue, every page that takes 6 weeks to ship, every test that gets blocked by an integration limitation — that’s the cost of staying. Migrations done with the discipline above typically recover or improve rankings within 30–60 days, while the velocity unlock starts on Day 1.
The actual question isn’t ‘should we risk a migration?’ It’s ‘how much longer can we afford the platform we have?’ The math usually answers itself.
Original Insight — the Ammo Migration Lift
Most agencies treat migration as a port. Same content, new platform. We treat it as the rare moment when you get to fix what’s been wrong for years.
We migrated M13’s site from Contentful — 438 pages in 21 days. Their team called it ‘unheard of in web development.’ We moved Bigeye’s complex data platform site in under 30 days. We migrated Uniqode (100K+ monthly visitors) to Webflow Enterprise with full SEO equity preserved. The pattern across all three: aggressive content audit during the migration window itself. We didn’t just rebuild what was there. We cut the thin pages, consolidated the duplicate ones, and rewrote the underperformers. The result is rankings that don’t just recover — they often climb past the pre-migration baseline within 90 days, because Google rewards the leaner, higher-quality content set.
