Service

Website Migration

For businesses and publishers leaving an ageing CMS, a hosted platform or a site nobody can maintain, who need content, URLs, media and data moved without losing what the old site built up.

The problem

What goes wrong today

Where it usually starts

The site that needs migrating is usually old enough to be a liability.

  • The CMS is two major versions behind because the upgrade breaks the theme, the plugins are abandoned, and the developer who built it no longer answers.
  • Editors have learned which buttons not to press.
  • Years of articles, product pages, documents and images sit in a database with a structure nobody fully understands, with URLs that were generated by three different schemes as the site evolved.
  • Some of those pages are what bring visitors today, and the fear of losing them is the reason the migration has been postponed again.

Where it gets harder

Previous attempts went badly: a redesign that launched with half the archive missing, a platform move where every old link returned a not-found page for a month and the traffic charts fell off a cliff, an import that lost authors, dates and categories so every article appeared published yesterday by "admin". The business knows it must move, and has a clear picture of where it wants to go; what it needs is a migration that treats the old site as an asset to be carried over carefully, with every URL accounted for, every record mapped and the result measured rather than assumed.

Scope of the service

What the build covers

A migration normally covers four things: an inventory of the current site, the content and data mapping, the redirect map and the measurement around the move. The inventory lists every URL from the server logs, the sitemap, the database and a crawl, with its traffic and inbound links where you have the data, and every content type, field, taxonomy, author, media file and document. The mapping decides how each content type becomes a type in the new content model, with authors, dates, categories, tags and attachments preserved, and how the data behind it, such as customers, orders, members or listings, is transformed and loaded. The redirect map pairs every old URL with a new one or an explicit decision to retire it, is tested automatically before launch and stays in place afterwards, with old URLs never silently dropped.

Measurement means recording the current site's crawl errors, index coverage, page timings and the pages that receive traffic before the move, and checking the same things after it so any regression is seen quickly and fixed. The new site is built to the standards described on the website development service, or your content lands in a system you already have.

When the scope grows

Scoping scenario

A regional news publisher with fourteen years of articles on an unsupported CMS, three URL schemes, two hundred thousand images and a paywall list wants to move to a maintained platform with the archive intact and every old URL redirecting. The archive size, the URL history and the subscriber data make this a project, and the scope document lists each content type, the redirect rules and what is retired.

Deliberately out of scope

  • Rewriting content, redesigning the business's offering and search engine advertising. We describe what we measure and how redirects are tested
  • We do not promise search rankings or traffic outcomes, which depend on factors beyond the migration

Deliverables

What you receive

  • A complete inventory of URLs, content types, media, documents and data on the current site
  • A written scope document with the content and data mapping, the redirect rules and what is retired
  • A tested redirect map covering every old URL, installed before launch and kept afterwards
  • Migrated content and data with authors, dates, taxonomies and attachments preserved and reconciled
  • A measurement baseline taken before the move and a comparison report after it
  • Training for editors on the new content model where the destination is a site we build
  • Handover material including the mapping scripts, the redirect map and full ownership of the result

Process

How a project runs

Each stage maps onto the project view in your client panel. Durations are set in your proposal, never on this page.

  1. Onboarding

    Access to the current site, database, server logs, analytics and search console; a first crawl and export.

    Project stage: Onboarding
  2. Planning

    Inventory completed, content types and data mapped, redirect rules agreed, retirements listed; all written into the scope document.

    Project stage: Planning
  3. Design

    The new content model and URL scheme designed around the inventory; page templates designed where a new site is built.

    Project stage: Design
  4. Development

    Mapping scripts built and run repeatedly against fresh exports; redirect map generated and tested automatically.

    Project stage: Development
  5. Client review

    Editors check migrated content against the old site, spot-check redirects and confirm the retirement list.

    Project stage: Client review
  6. Revisions

    Mapping corrections made and the migration re-run from a fresh export until the reconciliation is clean.

    Project stage: Revisions
  7. Ready for launch

    Final export and run, baseline measurements recorded, the old site frozen, DNS and redirects switched in a quiet hour.

    Project stage: Ready for launch
  8. Delivered

    The new site is live; measurements are compared against the baseline and the old site is archived.

    Project stage: Delivered

Integrations

Commonly integrated

Systems this kind of business usually asks us to connect. Each integration is confirmed during discovery; none is assumed.

  • Search console and analytics tools for the baseline and comparison
  • The current CMS or platform's export, API or database
  • Media storage and image processing services for archives
  • Subscriber, membership and paywall systems
  • E-commerce platforms for products, customers and order history
  • Email platforms for subscriber lists and consent records
  • Content delivery networks and hosting for the cut-over

How we would approach it

Worked example

Concept demo

A regional news publisher with a fourteen-year archive and three URL schemes

The situation

A publisher wants to leave an unsupported CMS holding fourteen years of articles, two hundred thousand images, three generations of URL structure and a subscriber list with paywall entitlements.

Why it is a custom build

The custom route is needed because the archive size, the three URL schemes and the subscriber entitlements require mapping scripts and tests written for this site, not a generic import tool.

The scope we would propose

  • A URL inventory from logs, sitemaps and the database with traffic recorded per URL
  • Mapping of articles, authors, sections, tags and images into the new content model with dates and bylines preserved
  • A redirect map with rules per URL generation and an automated test that requests every old URL
  • Migration of subscribers and entitlements into the new paywall
  • A measurement baseline covering index coverage, crawl errors and page timings
  • A comparison report after launch

Pricing

What affects the price

Every proposal is priced on scope. These are the factors that move it most for this kind of build.

  • Number of URLs, content types and the number of URL schemes to map
  • Archive size: articles, pages, media files and documents
  • Data behind the content: customers, orders, members, listings or entitlements
  • Condition of the current platform and whether a clean export is possible
  • Whether the destination is a site we build or a system you already have
  • Multilingual content and regional variants
  • Measurement and reporting requirements around the move
  • Hosting choice for the new site: your own hosting or ours

FAQ

Frequently asked questions

Will we lose search visibility when we move?

A migration changes URLs, structure and sometimes content, and search engines respond to those changes over time. What we control is the mechanics: every old URL mapped and redirected, content preserved with its dates and authors, metadata and structured data in place, and a baseline measured before the move and compared after it so any regression is seen and acted on. We describe the measurement; we do not promise ranking or traffic outcomes.

What happens to old links, bookmarks and shared URLs?

They keep working. The redirect map pairs every old URL with its new location or with a deliberate retirement, is tested automatically against the full URL list before launch and remains in place afterwards. Retired URLs return a proper not-found response with a useful page rather than silently disappearing.

Can you migrate to a platform we already use?

Yes. The destination can be a site we build, described on the website development service, or a platform you already run, provided it offers an import route. Content-heavy sites usually land on something like the news publishing package, shops on the online shop package and listing sites on the business directory package; the scope document names the destination and what it can hold.

How do you make sure nothing is missed?

By reconciling: counts per content type, per author and per year on the old site are compared with the new one after every migration run, and the run is repeated from a fresh export until the figures match or every difference is explained. Editors spot-check content and redirects before launch.

How long is the old site kept?

It is frozen at the final export and kept in read-only form for a period agreed in the scope document, so any question about a migrated record can be checked against the original. After that it is archived and the hosting can be cancelled.

Get a project quote for website migration software

Answer a few questions about your business, your current systems and what should change. We reply with a clear, competitive proposal.

Get a project quote