We are a website migration agency for teams that have outgrown WordPress, Drupal or AEM and cannot afford to lose search traffic on the way out. Most of our clients are a CTO or a Head of Marketing with a site that ranks well, loads slowly and is hard to edit. We move the content and the frontend to a modern stack, keep the URLs that earn traffic, and prove parity before launch. We do not move files between shared hosts. Book a migration assessment.
What a website migration agency actually does
A website migration moves a live site to a new platform, structure, domain or server while the old one keeps serving visitors and search engines. Copying the content is the easy part. The hard part is making sure that every URL, redirect, piece of metadata and tracking tag still works on the day you switch.
An agency owns that whole chain. It audits what you have, maps it to the new system, builds and imports, tests the result against the old site, and stays on after cutover to catch what slipped. If you are asking “how do I migrate my website”, the answer depends on which kind of move you are making.
Four kinds of website migration
| Type | What changes | Do we take it? |
|---|---|---|
| Platform (CMS to CMS) | The content management system, for example WordPress to Payload or Drupal to Strapi | Yes. This is most of our work |
| Architecture (monolith to headless) | The CMS is split from the frontend, and the frontend is rebuilt in Next.js or Astro | Yes. Usually together with a platform move |
| Domain and URL structure | The domain, the subfolders or the URL patterns | Yes. As part of a replatform or on its own |
| Hosting only | The server, with the same CMS and the same files | No. Your new host’s transfer service is faster and cheaper |
A hosting move is a copy of files and a database. Most hosting providers offer it as a support service, and you do not need an agency for it. The other three change how your site is built, and that is where rankings get lost.
Our website migration services
We handle the move end to end, but most projects lean on one or two of the services below. Each has its own deliverables, so you can scope only what you need. For the wider picture, see all migration services.
CMS migration
We move content out of WordPress, Drupal and Adobe Experience Manager into a headless CMS such as Payload, Strapi or Sanity. First we model content types, authors, taxonomies, media and redirects in the new system. Only then do we write import code. The common routes have their own pages: WordPress to headless CMS migration, Drupal migration and AEM migration. Each one covers the traps of that platform, such as WordPress shortcodes and page builder markup, multilingual Drupal nodes, or AEM component trees.
Frontend and platform migration
Many legacy sites render every page on the server for every request. We rebuild the frontend with static generation or incremental regeneration, so pages come from a CDN. We work mostly with Next.js development and Astro. We keep your current design unless you ask for a redesign, and we map old templates one to one, so editors find the same page types they already know.
SEO-safe migration
This is the part that protects revenue. We build a URL map from a full crawl plus your analytics and Search Console data. We write a redirect rule for every URL that has to change, and we carry over titles, descriptions, canonicals, structured data and hreflang. We regenerate the sitemaps and measure Core Web Vitals before launch. If you want an independent review of the current site first, our technical SEO consulting covers it.
Content and data migration
Nobody on our side copies and pastes content. We write import scripts against the old database or API, run them in batches, and produce a diff report so editors can review gaps before cutover. Checksum validation confirms that every record arrived intact. Every run writes to an audit log, so a failed batch can be traced and run again.
Our migration process in six stages
Every project follows the same six stages. The order matters more than the tools. Each stage ends with a named sign-off, so nobody finds out on launch day that a decision was never made.
1. Inventory and benchmark
We crawl the current site, export traffic and rankings, and list every template, content type and integration. We measure the new site against this baseline. Your marketing or SEO lead signs off the list of pages that must not lose traffic.
2. URL and content map
Every old URL gets a target: keep, redirect or retire. Content types are mapped to the new schema field by field. Your SEO lead signs off the URLs, and your content lead signs off the schema.
3. Build and import
We build the new CMS and frontend, then run the import scripts against a copy of production data. Every run is diffed against the source. Your engineering lead reviews the code and the import report.
4. Redirect and metadata layer
Redirect rules live in version control, not in a plugin, and we test them against a live crawl of the old site. Metadata, canonicals and structured data are checked template by template. Your SEO lead approves the redirect file.
5. Staging QA
We crawl staging and compare it with the old site: status codes, titles, canonicals, hreflang, internal links and Core Web Vitals. Editors run their real publishing tasks on staging. The product owner and the editorial lead sign off.
6. Cutover and watch period
We switch DNS or routing in a planned window, with a written rollback plan. After launch we watch Search Console coverage, server logs and rankings, and we fix gaps as they appear. You close the project when the agreed metrics match the baseline.
What we hand over at cutover
| Deliverable | What it contains | Who uses it |
|---|---|---|
| URL map | Every old URL with its target and status | SEO and marketing |
| Redirect file | Version-controlled rules, tested against a crawl | Engineering |
| Crawl diff report | Old site versus new site, page by page | SEO lead |
| Core Web Vitals report | Lab and field data, before and after | Product and engineering |
| Rollback plan | Steps and owners to revert if a launch check fails | Everyone on launch day |
How much does a website migration cost?
Two sites with the same page count can need very different work, so a flat price would be a guess. We scope every project after a short audit of your current site. The quote is a fixed scope with named deliverables. These are the things that move the number.
| Scope | What drives the cost | What drives the timeline |
|---|---|---|
| Marketing site | Number of templates, design changes, forms and third-party integrations | The content freeze date and how quickly sign-offs come back |
| Content-heavy site | Content model complexity, media volume, legacy plugins or modules that hold data | How many import runs it takes to get a clean diff |
| Multilingual enterprise | Number of locales, hreflang setup, translation workflow, accessibility and compliance rules | Review cycles per locale and the number of stakeholders |
| Publisher | Article volume, author and taxonomy structure, ad and analytics tags, ranking exposure | Size of the URL map and the length of the watch period |
A few factors apply to every row. Changing URLs costs more than keeping them, because each changed URL needs a redirect, a test and a watch. A redesign done during the migration adds scope and risk, so we usually migrate first and redesign second. And hourly billing on an open-ended migration tends to run long, because nobody owns the end date.
On timing: both migrations below were delivered within Q1 and Q2 2024, from discovery to launch. You get a dated plan with the quote. Book a migration assessment to start the audit.
Proof: two migrations with no ranking loss
SEO-safe CMS migration for a US enterprise digital publisher
A US-based enterprise digital media publisher had thousands of articles on a legacy WordPress installation. A decade of plugins added over 800ms to TTFB on article pages. The site ranked for thousands of commercial queries, so any URL change carried real business risk.
We moved the content to Payload CMS and rebuilt the frontend in Next.js with static generation for article pages. A custom script pulled posts, taxonomies, authors and media straight from the WordPress database. A Next.js middleware layer handled the few URLs that had to change, and no redirect chains were introduced.
Results: LCP on article pages fell from 4.2s to 1.5s, TTFB dropped by about 65%, and 0 organic ranking positions were lost at cutover. Read the full case: SEO-safe CMS migration for a digital publisher.
Drupal to Next.js replatform for a European enterprise healthtech organization
A European enterprise healthtech organization had to leave Drupal 7 before it reached end of life. The site carried over 1,200 content nodes across four languages, a custom medical disclaimer system in the theme layer, and WCAG 2.1 AA requirements.
A TypeScript pipeline pulled every node through the Drupal REST API, mapped it to Payload schemas and imported it with checksum validation and audit logging. Locale-aware routing in Next.js kept the existing URL structure and hreflang tags.
Results: LCP dropped from 4.3s to 1.5s, editor publish time fell by roughly half, and there were 0 SEO ranking regressions at cutover. Full write-up: Drupal to Next.js replatform for healthtech. For other stacks and industries, see more case studies.
How to choose a website migration agency
Agency rankings sort firms by size, reviews or awards. None of that tells you whether your traffic will survive the move. Ask these six questions, whoever you hire.
- Who owns the redirect map? One named person should own it, it should live in version control, and you should be able to review it before launch.
- How does rollback work? Ask for the written plan: what triggers it, who decides, and how long a revert takes.
- How are rankings measured after cutover? The agency should record a baseline before work starts and compare against it after launch, using your own Search Console data.
- What happens to analytics and Google Tag Manager? Tags, events and conversion goals break quietly. They belong in the QA plan, not in a post-launch ticket.
- Who stays on after launch? The first weeks after cutover show the gaps. Make sure the team that built the redirects is the team that fixes them.
- Is the scope fixed or hourly? Fixed scope with named deliverables gives you an end date. Hourly billing suits small, open tasks, not a full migration.
If you plan to run the project in house, our migration checklist walks through the same gates. If you would rather have one team manage it end to end, that is the service on this page.
Migration risks and how we prevent them
These are the failures we check for on every project, and the control we run for each one before launch.
| Risk | Where it shows up | Our control |
|---|---|---|
| Lost URLs | 404s in Search Console, pages dropping out of the index | URL map built from a crawl plus analytics, checked against a staging crawl |
| Redirect chains | Slow redirects, diluted link signals | One-hop rules in version control, tested against a live crawl |
| Dropped metadata | Missing titles, descriptions and canonicals | Template-by-template checks and a crawl diff before launch |
| Broken hreflang | Wrong language version served in search | Locale-aware routing and hreflang validation on staging |
| Core Web Vitals regression | Slower LCP or layout shifts on the new site | Lab and field measurements before and after cutover |
| Analytics gap | Missing sessions or conversions after launch | Tag and event inventory in QA, side-by-side tracking at cutover |
Book a migration assessment
Send us the site, the target platform you have in mind and your launch window. We crawl the site, record a baseline and come back with a fixed scope, a dated plan and the risks we see. Book a migration assessment.
