JOURNAL — 013 · Development

How We Migrate Sites Without Losing a Single Ranking

Humdan Ali, Founder & Technical Director October 10, 2025 4 min read
How We Migrate Sites Without Losing a Single Ranking — journal featured image

Migrations fail at the spreadsheet, not the server. The redirect-mapping discipline that has carried 14 domains across platforms with traffic intact.

The scariest ticket in this industry is 'we replatformed and traffic fell off a cliff.' It's also the most preventable. Rankings survive when every URL has a mapping, every canonical is deliberate, and somebody watches Search Console like a hawk for 30 days.

Audit before architecture

Every rebuild that goes smoothly started with an inventory nobody wanted to write: templates in use, plugins with business logic buried inside, integrations with tribal knowledge as documentation. Skipping the audit doesn't save the week — it bills the month.

We export the plugin list, crawl every template, and interview whoever touches the site weekly. The output is a one-page map of what the site actually does, as opposed to what anyone remembers it doing.

Ninety percent of rebuild surprises were knowable on day three. The other ten percent are why timelines have buffers, not excuses.

The launch-week readiness list

  1. Backups verified by an actual restore, not a green dashboard icon
  2. Rollback plan rehearsed: one command back to last-known-good
  3. Error monitoring on production with an owner assigned
  4. Core Web Vitals re-tested on production hardware, not staging
  5. 301s spot-checked from the old sitemap, robots and canonicals audited
  6. The 'who gets paged' list updated and acknowledged before Friday

Technical debt has an interest rate

Nobody feels technical debt on the day it's taken. It arrives eighteen months later as 'a simple change' quoted at three weeks: the workaround that became load-bearing, the plugin forked and now unforkable.

The honest measure is drag per quarter — how much slower is each change than the one before it. When drag doubles, consolidation pays for itself faster than new features.

Refactoring for elegance is vanity. Refactoring to restore change-speed is maintenance, and it's usually overdue before anyone schedules it.

A plugin is a promise made by a stranger. Choose few, choose well.Internal review, 2025

Maintenance is a product

Sites don't decay because of hackers and core updates; they decay because nobody's job is 'keep it excellent.' Updates run until something breaks, then maintenance gets funded retroactively with interest.

The retainer structure that works is small and relentless: weekly updates in staging, monthly regression checks, quarterly performance and uptime reviews, and a human who knows the site answering within hours.

The build-vs-plugin line

Every plugin is a dependency with its own author, roadmap and security record. Our line: if a requirement is core to the business and stable, build it natively; if it's peripheral and moving, rent it.

Custom code is not automatically better — badly written custom code is worse than a mature plugin. The calculus is control over the parts that make you money versus maintenance on the parts that don't.

A healthy WordPress or Shopify build in 2026 is quietly boring: few dependencies, all understood, everything load-bearing owned.

We don't do rescue projects anymore. We do builds that never need rescuing.Humdan Ali, founder

Where to start this week

Crawl your current site today and freeze that URL inventory — even if the migration is six months away. The crawl you have is worth more than the crawl you'll wish you had.

Then keep it honest with a short list:

  • Every change request returns with a bigger estimate than the last one
  • Two plugins conflict and the fix is a third plugin
  • Mobile LCP is over 4 seconds and nobody remembers why
  • Put the date on the calendar — playbooks without Fridays are just reading

And when the scope outgrows the spreadsheet, that's precisely what our team is for.

Straight answers

How long does a typical WordPress or Shopify build take?

Six to ten weeks for most marketing sites and stores: two for discovery and architecture, three to five for design and build, and one hardening week we refuse to skip. Rushed timelines are available; we just document what you're trading.

Who owns the code and hosting?

You do — repositories, credentials, hosting, everything. Agencies that hold infrastructure hostage are telling you about their retention strategy, not their confidence in their work.

How do you handle deployments and downtime risk?

Versioned releases to staging first, database-free deploys where possible, rollback rehearsed before it's needed. Launches happen mid-week mornings, never Fridays, never unattended.

Humdan Ali
Founder & Technical Director · ALIFY

Runs ALIFY's engineering floor. Has shipped 250+ builds and still reviews every launch checklist personally.

Start a project

Like how we think?

Imagine what we ship. Intro call + fixed quote in 48 hours.

Cookies, minus the crumbs. We use essential cookies to run this site and optional analytics cookies to improve it — analytics only load after you accept. See our Cookie Policy.