What to ask a developer before migrating your website to a new platform

Ask a developer the right questions before migrating your website to a new platform, so content, links, and enquiries survive the move.

What to ask a developer before migrating your website to a new platform

Moving a website to a new platform is one of the few projects where a single oversight can erase years of search visibility, break every enquiry route, and leave the business without a working website for days. The platform itself is rarely the problem. The problem is the work that was assumed, rather than asked about and agreed in advance.

The questions below are not technical tests. They are the questions that protect content, rankings, enquiries, and the relationship with the developer. Ask them before signing anything, and ask for the answers in writing, so both sides are working from the same plan.

What will happen to every page and URL

Ask for a complete inventory of the current site: every page, every URL, and every piece of content that will move, change, or be removed. Then ask how each URL will be handled on the new platform. Pages that disappear without a redirect will lose their rankings and break links from other websites, including guest posts.

Ask who owns the redirect map, and when it will be tested. A redirect map created on launch day, under pressure, will contain errors. One created and tested on staging, with the most important pages checked individually, will not.

What will happen to forms, tracking, and integrations

Ask how enquiry forms, booking tools, payment links, chat widgets, and analytics will be rebuilt on the new platform, and how each one will be tested. A form that looks identical but sends its submissions to the wrong address is a common migration failure, and it is invisible until someone notices the enquiries have stopped.

The same discipline applies to any redesign or launch. The article on how to preserve enquiry forms and tracking when a redesign goes live sets out the inventory and testing approach that keeps forms and measurement working from the first day on the new site.

Who owns the content, and in what form

Ask who is responsible for moving content, and what will happen to images, documents, and metadata. Content migration is often underestimated, because it looks like copying and pasting. In practice, it involves checking every page, re-adding images at the right sizes, and confirming that headings, links, and formatting survived the move.

Also ask what happens to the old platform. Will you keep access to it, and for how long? Will the content be exported in a usable form? A business should never be locked out of its own content because a migration moved it into a system it cannot export from.

What will change for search visibility

Ask how page titles, descriptions, headings, and structured data will be preserved, and how the new site’s speed and mobile experience compare with the current one. A faster, cleaner platform can improve rankings, but only if the content and links that earned those rankings are preserved.

Ask for a baseline report before migration: rankings, traffic, and enquiries for the most important pages. Without a baseline, nobody can tell after launch whether the migration helped, harmed, or made no difference. With one, problems can be spotted within days, while they are still easy to fix.

What is the timeline, and what happens if it slips

Ask for a realistic timeline with named milestones, and ask what happens when a milestone slips. Migrations slip for understandable reasons: content takes longer, integrations behave differently, or a feature on the new platform does not work as expected. A plan that has no slack will launch unfinished, or launch late without warning.

  • Content freeze: the date after which no changes are made to the old site.
  • Staging review: the date you can test the new site as a visitor would.
  • Launch window: a quiet period, with support available afterwards.
  • Rollback plan: how the old site is restored if the launch fails.

Frequently asked questions

Will migration hurt my search rankings

It can, temporarily, if URLs change without redirects or content is lost. With a complete redirect map, preserved titles and content, and a tested launch, any dip should be small and short-lived. A large, lasting drop usually means something in the migration was missed.

How long does a platform migration take

It depends on the size of the site and the complexity of its integrations. A small brochure site may take a few weeks. A larger site with forms, bookings, and custom features may take several months. Be wary of a timeline that seems too short for the amount of content involved.

Should I migrate and redesign at the same time

If possible, separate them. Migrating on the existing design, then redesigning once the new platform is stable, makes it easier to tell whether a problem came from the migration or the redesign. Doing both at once is possible, but it needs a more careful testing plan.

What should be in the contract

The scope, the redirect plan, the testing checklist, the timeline, the support period after launch, and who owns the content and data. Vague promises about a smooth migration are not a substitute for a written plan that names what will be preserved and how it will be tested.

Can I keep my domain and email during migration

Yes, and you should confirm the details in advance. Ask how domain settings and email will be handled, and whether any change will affect email delivery. Email problems are a common and disruptive side effect of a poorly planned migration.

A migration is a business decision, not only a technical one. Ask the questions that protect the content, the enquiries, and the rankings the business has already earned, and the new platform will be a step forward rather than a fresh start.

Leave a comment

Your email address will not be published. Required fields are marked *

Related reading

Tell us what you are trying to grow.

Send the details of your project and you will get a considered reply — scope, approach and next steps, not a template.