Website migration scope: a checklist before you quote
Scope a website migration with a URL inventory, content decisions, redirect ownership and launch checks. Includes an example work breakdown.
“Move the website” can mean copying ten approved pages or untangling years of content, downloads, redirects and platform behavior. The visible page count is only one part of the quote. A useful migration scope names what is moving, what is changing, what will be retired and who is responsible for checking the result.
Count the source material before counting new pages
Ask for an inventory of existing URLs and content types. Include articles, service pages, landing pages, downloads and other assets that matter to the business. Record where the inventory came from and what may be missing. A navigation menu rarely represents the entire site.
Separate unique content from reusable layouts. Forty articles might use one layout but still require forty content decisions and checks. Conversely, a six-page site can contain complex forms, embeds and account areas. Quote these components explicitly instead of assuming that every page represents the same amount of effort.
For each item, propose a disposition: keep, revise, combine or retire. The client should approve business decisions such as removing an old service page. Do not let a developer’s incomplete export become an accidental content strategy. The baseline guide is a useful place to document the approved inventory.
Make the migration map a real deliverable
For moves that change URLs, Google’s site migration guidance calls for mapping old URLs to their new destinations and configuring redirects. Include responsibility for that work in the scope rather than assuming it is part of an undefined “SEO setup.”
A practical mapping sheet needs an old URL, proposed destination, content decision, owner and verification status. If three old pages are being combined, the destination should make sense for people following those old links. Flag unresolved destinations before launch instead of creating a catch-all plan that nobody has reviewed.
The map is also an estimating tool. A project with five unresolved content consolidations has a different risk profile from a project with a fully approved one-to-one mapping. Quote the review meetings and implementation work needed to resolve those differences.
Scroll sideways to see all columns.
| Work package | Required input | Definition of done |
|---|---|---|
| Content transfer | Approved inventory | Selected content present |
| URL mapping | Destination decisions | Every in-scope URL assigned |
| Redirect setup | Approved map | Specified redirects checked |
| Launch review | Agreed test list | Results and exceptions recorded |
Name responsibilities across the launch boundary
Before quoting, identify who controls the old host, new host, domain configuration and content system. Record access as a dependency, not as a password request inside a shared scope document. A supplier can be responsible for making a change only if the relevant access and authorization are available.
Split launch responsibilities into preparation, switch-over and follow-up. Preparation might include testing forms on a staging environment. Switch-over might include an agreed publishing window and a person who can authorize rollback. Follow-up might include checking key pages and recording issues against the approved acceptance list.
Do not promise uninterrupted traffic or rankings. The project can include careful migration work and documented checks; it cannot guarantee how external search systems respond. State the support period and the kinds of post-launch corrections included so that “keep an eye on it” does not become an unlimited commitment.
- Who approves the launch and who can pause it?
- Who implements domain or hosting changes?
- Who checks forms, analytics configuration and important journeys?
- How long is the included post-launch review period?
Estimate by work package, then expose assumptions
Imagine a small migration with eighteen content pages. Your illustrative estimate includes six hours for inventory and mapping, twelve for transferring approved content, eight for redirect and component setup, and six for launch checks and handoff. That is thirty-two hours before any content rewriting or new functionality.
The useful part of this estimate is the breakdown, not the number. If the client decides that eight pages need fresh copy, you can identify the new work clearly. If the inventory expands, you can compare the additional items with the approved baseline rather than debating whether they count as “part of the website.”
Use the scope change calculator to model the effect of extra work on your fee. Keep allowances specific: how many pages, what format the source content must be in, and how many review rounds are included. Undefined allowances are difficult for either party to manage.
Treat launch exceptions as decisions, not loose ends
During the final review, classify each issue. A failed in-scope form needs a correction. A new request for an appointment system needs a separate decision. A client’s missing legal page may block launch or be explicitly deferred by the responsible owner. These situations should not share one undifferentiated punch list.
Create a handoff that names what was delivered, what remains open, who owns it and when it will be reviewed. Keep the approved mapping and test results with that record. A migration is easier to maintain when the next person can see why a destination or exception was chosen.
When a new request affects the launch window, use the change order template to explain both price and schedule. The best time to make that trade-off visible is before the team has committed to a launch that the revised scope no longer supports.
