Website migration scope: what to check before quoting a redesign

Before quoting a website redesign, agree which existing pages and files must survive, which addresses will change, who can access the old systems, and who will check the move. Put that work in the estimate alongside design and development. A page count on its own leaves too much unanswered.

This guide is for creative agencies commissioning a replacement client website. The aim is a migration schedule your client and developer can price and approve. An online shop, membership platform or multilingual site will need additional specialist scoping.

Establish what is moving

A hosting change can leave every public address intact. A redesign might also change the CMS, content and URLs. Ask the developer to identify those changes separately before treating them as one job. Google has separate guidance for hosting moves that keep URLs and moves that change URLs.

Write down the proposed domain, content platform and URL structure. Confirm whether email or other services depend on the same domain settings, and name the person who will check those dependencies before a hosting change.

There may be a good reason to keep an awkward-looking address. Ask what changing it achieves before adding another migration task to the quote.

Ask for evidence before fixing the price

Request a content export or page inventory, existing sitemaps, Search Console access and whatever useful analytics the client has. Include important downloads. Google's site-move guidance describes using several sources to find old URLs, including CMS records, traffic logs and linked pages.

Use that inventory to ask:

• Is each item being carried across, rewritten, combined with another page or removed?

• Who approves that decision, and when will they provide replacement copy?

• Can the developer export the content cleanly, or does someone need to rebuild each entry?

• Are files and images available in usable originals, with permission to reuse them?

• Which pages support enquiries or active campaigns that the client wants checked first?

Record missing access as an unresolved dependency. If nobody has seen the old CMS export, describe content transfer as provisional and agree a separate inspection step before committing to its cost. Avoid burying that uncertainty in a fixed number of “migration hours”.

Keep account access in the client's agreed secure system. The scope document needs an account owner and an access status, not passwords or customer records.

Give every old address a decision

This is a hypothetical planning example for a small professional-services website. The paths and decisions illustrate the work; they are not a client case study.

The table contains five decisions but six old URLs. Count addresses as well as decisions when agreeing the checking effort. A simple rule might handle many redirects, while one awkward legacy address might need individual investigation. Neither the number of new designs nor the number of redirect rules tells you how much content review is involved.

For a permanent move, Google recommends server-side permanent redirects where possible, including HTTP 301 or 308. The developer should choose and test the appropriate implementation for the platform. See Google's redirect guidance.

Do not send every removed page to the homepage. Google warns that irrelevant destinations can be treated as soft 404s. A relevant consolidated page can be a suitable destination; content removed without a replacement should return an appropriate 404 or 410 response. Keep redirects pointing directly to their final destination. These distinctions are covered in Google's site-move guidance.

Turn the inventory into a quote

Break the work into units the client can recognise. Agree which content types can be imported, which entries need manual rebuilding, who rewrites outdated copy, and who approves the URL map. Record the actual counts once the inventory is checked.

Quote testing and launch support explicitly. Decide who checks the old addresses, who verifies the new content and who handles problems after release. If another supplier owns SEO, agree how their approval fits the launch date.

Include responsibility for maintaining redirects after launch. Agree their retention period and any continuing hosting costs with the developer and SEO owner before closing the migration budget.

Use the migration scope worksheet alongside the brief to record included work, owners and completion evidence. That evidence confirms the agreed work has been checked. It does not guarantee unchanged search performance.

Keep copy changes after approval visible. If the client removes a service during development, update its destination decision and the testing scope before launch.

Agree launch checks while there is time to price them

Ask the developer how the test site is protected. A robots.txt block alone does not reliably keep a URL out of Google, and it can prevent Google from seeing a noindex instruction. For confidential staging, specify authenticated access rather than relying on search settings to keep it private. See Google's indexing-block guidance.

Include a release check for the intended public pages' indexing settings, preferred URLs (canonical tags), sitemap and internal links. Keep any intentionally private areas protected.

Ask for the result of a live enquiry test, including receipt at the agreed destination. A success message alone does not prove delivery.

Agree the recovery decision before changing the live site. Name who can stop the release, how the previous version can be restored, and how any enquiries or other data received during the change will be retained. For a hosting move, Google recommends checking traffic on the old and new infrastructure before shutting the old hosting down. See its hosting-move guidance.

Budget for the period after launch

Book a technical check immediately after release and agree later review dates with the client. Save the pre-launch search and enquiry baseline so those reviews have something to compare with. Track form failures separately from changes in visits.

Search Console's live URL test checks potential indexability. It does not guarantee indexing or predict which URL Google will choose as canonical. Its indexed-page report describes Google's recorded version, which may lag behind a recent change. The URL Inspection documentation explains those limits.

Google also warns that rankings can fluctuate during a move. Do not promise an unchanged ranking or a fixed recovery date.

Agree who investigates a decline, what information they will use and what follow-up work is included in the quote. An enquiry tracking change can affect the numbers you see, so check the measurement before attributing every difference to the redesign.

Bring the migration questions into the brief

Add the inventory and unresolved decisions to the website development brief. They give your developer something specific to inspect before you commit to the client price.

If you are commissioning a client rebuild and need help working out the delivery scope, bring the brief to Kyln. Include the existing website address and what you expect to change. Leave credentials and customer data out of the enquiry.