Somebody has asked you what a migration would cost, and you have to come back with a number.
Here is how one gets made. A provider needs three things about your site before any figure is possible, a half-hour conversation usually covers all three, and what comes out of it is a rough number rather than a price. After that the number moves, and what moves it is how quickly your own organisation can decide things.
Our published project fee range and the monthly figure for technical ownership after launch both sit in the headless CMS migration guide. This post is about the other half of the question: how a provider gets from your site in particular to a number for it.
What does a provider need before they can give you a number?
“size of page. amount of traffic. i need to grasp the complexity of the page.. usually after a 30min talk i can give a rough estimate already”
That is David, who prices our migrations. Each of those three means something slightly different on a migration than it does on a new build.
- Size. Not the page count. The number of page types that are actually different from one another, because a page type is a template, a content model and a set of editor decisions all at once. Two hundred pages built from four templates is a smaller job than forty pages built from nineteen.
- Traffic. Here it is a risk input before it is a hosting input. Traffic by URL decides how much of the redirect map is load-bearing and how much of the search work has to be proven before cutover instead of after. The redirect strategy for a migration goes through that part in detail.
- Complexity. What the site is wired into. Integrations, second and third languages, authenticated areas, and how deep the existing content model goes. This is the input a provider cannot infer from the outside of your site, and it is the one worth preparing before the call.
Half an hour on those three is enough for a rough estimate. That is our own operating practice, and it works because the three inputs fix the scale of the job even while the detail is still open.
What a thirty-minute conversation can and cannot settle
The call produces three things:
- An order of magnitude, wide enough to take back to whoever holds the budget.
- A verdict on whether this is a migration or a rebuild. Those are different projects with different numbers.
- A read on whether the picture is clear enough to price at all.
A fixed price is not one of them. Between the rough number and the fixed number sits a scoping pass, where the assumptions get turned into a described scope. On our side that is the Essential Launch Framework. Where the current setup is hard to read from the outside, a headless audit does the same work as a paid piece with a written output.
You can shorten the conversation considerably by bringing material to it. Four artefacts do most of that work, and they are at the end of this post.
What turns a small migration into a big one
“decisions. missing decisions and not letting go of old stuff. too many stakeholders. no clear chain of command. client team is not emporered enough to make decisions”
Every one of those five is a decision problem inside the client organisation. The CMS, the framework and the page count sit outside the list entirely.
| The driver | How it shows up on a migration | What it does to the number |
|---|---|---|
| Missing decisions | A page type sits half-specified while the build waits on an answer | Work gets re-done rather than done once |
| Not letting go of old material | Every legacy page type gets rebuilt and every legacy URL needs a home | The most direct line there is from a decision to billable work |
| Too many stakeholders | Each review round adds names that were not in the last one | Rounds multiply, and every round is scope |
| No clear chain of command | Two answers arrive and neither one ends the question | Nothing gets settled enough to build against |
| A team not empowered to decide | The person in the meeting cannot approve what the meeting is for | The calendar sets the pace instead of the work |
Row two is the one that belongs to migrations specifically. On a new build, a piece of content nobody has decided on is simply absent. On a migration it already exists, it already has a URL, and somebody has to say out loud that it ends here. Anything nobody says that about gets rebuilt on the new stack and redirected to a new home, and both of those are work. “We will decide later” arrives at the estimate as “build it”.
Count the sign-offs before you ask for a number
Walk your current site and list the page types. Then write, against each one, the name of the person who signs it off. Pricing pages. Product. Careers. Legal. The blog.
That is twenty minutes of work and it does two things for you.
The first is practical. You now have the list a provider is going to ask for, so you can answer the complexity question during the call instead of a week later.
The second is that you get to see your own decision chain. Where one page type has four owners across three teams, every change to it is a scheduling problem before it is a work problem. Two items on David’s list, too many stakeholders and no clear chain of command, describe that same shape from the provider’s side of the table. Seeing it before the project starts means you can shorten it deliberately, by naming who signs off on what, rather than finding out in week six.
What happens when the estimate is wrong
“yes. mostly stakeholder management. sometimes also integration. when 3rd party stuff is WAY complicated than i though. BUT… thats part of the game for me. i stand by my word”
The thing we most often get wrong, then, is the same organisational driver the sections above are about. The other case is an integration, a third-party system we judged simpler than it turned out to be. Either way the estimating error is ours, and we stand by the quote we gave.
What to bring to the call
Four artefacts. All four are deliverables rather than decisions, so none of them needs a meeting first.
- A full crawl of the current site, exported. Every URL that returns a 200, not the sitemap. The sitemap is what somebody intended to publish. The crawl is what is actually there.
- Twelve months of traffic by URL, out of analytics or Search Console. This puts the redirect risk in front of the person doing the pricing rather than behind them.
- The list of page types with the person who signs off on each. The exercise above.
- Every third-party system by name and version. The CRM, the marketing automation, the translation vendor, the booking tool, whatever sends data in or takes it out.
The first two are exports and take a few minutes. The other two are half an hour of your own time. Together they are the difference between a range and a number.
The next step after that is a conversation. A call is where the three inputs get covered, and half an hour of it is usually enough for a figure you can take back to whoever asked you for one.
Where you need more than a figure, and specifically where a scope has to hold up in writing before anyone approves a budget, the headless audit is the paid version of the same work. Its own page carries the fee.