Moving Off WordPress: How a Contractor Site Migration Actually Works

Why Contractors Migrate Off WordPress in the First Place

Nobody wakes up wanting to migrate a website for fun. It's a maintenance-fatigue decision. The pattern we see in audits is consistent: a WordPress site built three, five, sometimes eight years ago, running a stack of plugins nobody remembers installing, on a theme that hasn't been updated because updating it might break the layout. The owner isn't chasing a trend, they're done being the site's unpaid systems administrator.

The three triggers that actually get an established contractor to pull the trigger on a migration: the site got hacked or flagged (Google Search Console shows a security warning, or a customer mentions the homepage looked wrong), the load time has crept up year over year until mobile visitors bounce before the hero image paints, or the previous agency has the login and won't hand it over cleanly. Any one of those alone is annoying. Together, they're the moment a contractor decides the plugin tax isn't worth it anymore.

What almost never triggers a migration on its own: wanting new copy or a new look. That's a redesign, and you can redesign inside WordPress without touching the platform. Migration is specifically about changing what the site runs on, not just what it says. If your only complaint is that the site looks dated, that's a different conversation than this one.

• Repeated hack or malware flags from Google Search Console or your host
• Load times that have degraded as plugins accumulated, hurting Core Web Vitals and mobile conversion
• A previous agency holding the login, theme license, or domain registrar hostage
• Plugin costs (premium theme, page builder, security plugin, form plugin) stacking into a real monthly bill
• Wanting integrations (ServiceTitan, Jobber, Housecall Pro, CRM) wired directly instead of through a third-party plugin

If none of those describe your situation, WordPress with a lean plugin count and decent hosting can still do the job. Migration earns its cost when the platform itself has become the problem, not the content sitting on top of it.

Stage One: The Content and Traffic Audit

Every migration starts with an inventory, not a rebuild. Before a single line of new code gets written, the existing site gets crawled and cataloged: every URL, its current organic traffic, its backlink count, and what it ranks for. This is the step that gets skipped by cheap operators in a hurry, and it's also the single biggest predictor of whether a migration protects your rankings or tanks them.

The audit answers three questions. Which pages are actually earning traffic and need to survive the move exactly as they are? Which pages are dead weight (old blog posts with zero traffic, thin service pages, duplicate content) that don't need to be rebuilt at all? And which pages have backlinks pointing at them from other sites, meaning their URL has to redirect cleanly or that link equity evaporates?

For a typical established contractor site, this usually surfaces pages the owner forgot existed: an old "coupon" page from a 2019 promotion, a blog post that somehow ranks for a decent keyword, a service-area page for a city they stopped serving years ago. Each of those needs a decision (keep, merge, redirect, or 410-remove) before the URL map gets built in stage two.

This stage typically takes 3-5 business days for a contractor site in the 20-100 page range. Rushing it is the single most common root cause of a post-migration traffic drop, not the migration itself.

Stage Two: URL Mapping, the Step That Protects Your Rankings

This is the part that actually determines whether Google treats your new site as "the same business, new address" or starts over from scratch. Every URL on the old WordPress site gets mapped, one to one, to its destination on the new build. Where the URL structure stays identical, the mapping is trivial. Where it changes (and sometimes it should, if the old structure was a mess), every old path gets a specific 301 redirect to its new equivalent, never a blanket redirect to the homepage.

Google's guidance on site moves is explicit about this: a 301 redirect passes the vast majority of the ranking signal from the old URL to the new one, but only if the destination page covers the same topic. A redirect from an old plumbing-repair service page to a generic homepage doesn't pass that signal the same way, because the topical match is gone. This is why the mapping has to happen page by page, not as a shortcut.

• Old URL structure and new URL structure get laid side by side in a spreadsheet before any redirects are written
• Every indexed URL (check Google Search Console's coverage report) gets a mapped destination, no exceptions
• 301 redirects (permanent) get used for pages that are genuinely moving, not 302 (temporary), which doesn't pass ranking signal the same way
• Pages being intentionally retired get a 410 (gone) rather than a redirect to an unrelated page, which Google treats more honestly than a fake redirect
• The XML sitemap gets rebuilt to reflect only the new, live URL set

For contractors, the URL structure itself is often part of what improves in the move. A WordPress site built by a generalist agency frequently has messy paths (a mix of /blog/post-title/ and /2019/03/page-name/ and /?p=482 query strings). A clean migration is a chance to move to a consistent, readable pattern (this site uses /[service]-for-contractors/ as its own example) while still mapping every old URL to a new one so nothing that was ranking goes dark.

Stage Three: Rebuilding the Pages as Hand-Coded Static Files

With the audit done and the URL map locked, the actual rebuild starts. Every page that survives the cut gets rebuilt as static HTML/CSS/JS, no database, no plugin dependency, no page-builder markup bloat. The content itself (your service descriptions, your trade-specific copy, your photos) carries over. What changes is the machinery underneath it.

This is also the point where a migration and a redesign can happen together, but they don't have to. Some contractors want the exact same look and copy, just faster and off WordPress, a like-for-like technical rebuild. Others use the migration as the moment to also refresh dated copy or update photography. Either is fine, but it's worth deciding upfront which one you're paying for, because a pure technical migration is faster and cheaper than a migration-plus-redesign bundled together.

Every page rebuilt this way gets checked against the same standard: load time under 2 seconds, clean semantic HTML (which matters for both traditional SEO and how AI search tools parse and cite the page), and no plugin-generated bloat in the markup. WordPress page builders like Elementor and Divi wrap simple content in layers of nested divs and inline styles; a hand-coded rebuild strips that down to what the browser actually needs.

• Service pages, location pages, and blog posts get rebuilt with matched or improved content
• Images get compressed and served in next-gen formats (WebP/AVIF), a common quick win that WordPress sites frequently skip
• Schema markup (Service, FAQPage, LocalBusiness, BreadcrumbList) gets rebuilt cleanly instead of inherited from a plugin's default output
• Core Web Vitals get checked page by page, not just on the homepage, since Google evaluates them per URL

This stage is the bulk of the build timeline, typically 2-4 weeks depending on page count and how much content needs rewriting versus straight porting.

Stage Four: Rewiring Integrations (Booking, CRM, Forms, Call Tracking)

An established contractor's WordPress site almost never stands alone. It's usually wired, however messily, to a scheduling tool (ServiceTitan, Jobber, Housecall Pro), a CRM, call tracking numbers, a payment or deposit processor, and sometimes a chat widget or review platform. Every one of those connections has to get rebuilt for the new site, and this is where a rushed migration creates the outage a contractor actually notices: a lead form that stops routing, or a tracking number that goes silent.

On WordPress, these integrations are usually plugin-based: a form plugin posts to a Zapier webhook, which posts to the CRM. On a hand-coded static site, the same connections get wired more directly, a form posts straight to the CRM's API or webhook endpoint, a scheduling tool's booking widget gets embedded natively, a call-tracking script runs without a plugin dependency between it and the phone system. Fewer layers means fewer places a lead can silently vanish, but it also means every integration needs deliberate testing before cutover, not an assumption that "it'll just work" like a plugin update.

This is exactly the kind of wiring work this silo owns: getting the site talking correctly to the tools that already run your business. It's build-and-connect work, not a traffic or ranking campaign, and it deserves its own checklist before go-live, not a last-minute scramble.

Stage Five: Cutover, DNS, and the First 30 Days

Cutover day is when the new site goes live at the real domain and DNS points traffic to it. Done right, this is close to instant for visitors and shouldn't cause visible downtime, since DNS changes can be staged and the new site is fully built and tested (redirects included) before the switch happens. The riskiest mistake at this stage is flipping DNS before every redirect and integration has been verified live on a staging domain first.

The days immediately after cutover matter more than most contractors expect. Google has to re-crawl every redirected URL before the ranking signal fully transfers, and that doesn't happen instantly. It's normal, and documented by Google itself, to see some ranking volatility for days to a few weeks after a site move as the new URLs get crawled, indexed, and the redirects get processed. A temporary dip during that window isn't a sign the migration failed, it's the expected mechanics of a re-crawl. A dip that doesn't recover after several weeks is the sign something in the redirect map was wrong.

• Submit the new XML sitemap in Google Search Console immediately at cutover
• Use GSC's URL inspection tool to spot-check that key pages are being crawled and indexed under the new URLs
• Monitor the redirect map for 404s, any old URL that returns a 404 instead of a 301 is a link-equity leak
• Watch organic traffic and keyword rankings daily for the first two weeks, weekly after that
• Test every form, booking widget, and call-tracking number live on the production domain, not just staging

A contractor who's mid-migration and watching rankings wobble should expect this window, not panic through it. What should trigger a closer look is a specific ranking that fully disappears rather than dips, which usually traces back to a missed redirect in the URL map from stage two.

How Long It Takes and What Can Slow It Down

For a typical established contractor site (20 to 100 pages, a handful of integrations, no e-commerce), the full process from audit to cutover runs 3-6 weeks. Smaller brochure-style sites move faster. Larger multi-location sites with dozens of service-area pages and several software integrations run longer, closer to 6-10 weeks, mostly because the URL mapping and integration testing scale with page count.

The variables that actually move the timeline: how many pages need real content rewriting versus a straight technical port, how many third-party integrations need rewiring versus a simple re-embed, whether the current WordPress site's URL structure is clean enough to map directly or needs restructuring, and how quickly the contractor can turn around content review and approval rounds. That last one is the most common real-world delay, not the technical build.

1. Content and traffic audit: 3-5 business days
2. URL mapping and redirect plan: 3-5 business days
3. Page rebuild (the bulk of the timeline): 2-4 weeks
4. Integration rewiring and testing: 3-7 business days, often parallel with the rebuild
5. Cutover and first-30-days monitoring: 1 day to flip, 2-4 weeks of active watching

One honest caution: avoid any migration quoted at a flat "we'll move your site in 48 hours" price. That's long enough to move files, not long enough to audit traffic, map every URL, and test every redirect. A fast, cheap migration and a rushed one are usually the same thing, and the bill for skipping the audit and mapping stages shows up later as a ranking drop that takes months to diagnose and recover from.