Two questions come up in almost every first conversation about going headless. How much will it cost, and how long will it take. I understand why, because they are the two things a business owner actually has to plan around. But if a developer gives you a firm number on the first call, before they have seen your site, be careful. It is not that the answer is unknowable. It is that the answer depends on things they have not looked at yet. Here is the honest version of what drives both, so you can have a sharper conversation and spot a quote that does not add up.
Why nobody can price it on the first call
A headless migration is not one job. It is a content migration, a front-end build, a set of integrations, and a launch, bolted together. The same phrase, moving to headless, covers a five-page brochure site and a shop with five thousand products, a warehouse system, and a dozen third-party tools hanging off it. Those are not the same project with a different price. They are different projects. Anyone who quotes you before understanding which one you are is guessing, and a guess that comes in low is the one that hurts later.
What actually drives the cost
When I scope a migration, the number moves on a handful of things, and it is worth knowing them so you can see where your own money is going.
The first is how much content and data you have, and what state it is in. A few dozen tidy pages is quick. Thousands of products with years of inconsistent data, missing images and half-used fields is slow, because someone has to clean and map all of it, not only copy it. This is the part that is always bigger than people expect.
The second is integrations. Payments, stock, email, booking, a CRM, an accounts package. Every system your current site talks to has to keep talking to the new one, and each connection is its own small piece of work. A brochure site with a contact form is cheap here. A shop wired into a warehouse and an accounts system is not.
The third is how custom the front end is. A clean, fairly standard design built well is one cost. A pixel-perfect bespoke design with animation, complex filtering and lots of unique page types is another. The CMS side is rarely the expensive bit. The front end usually is.
The fourth is who does the content entry and the testing. If your team can move content and check pages, that saves real money. If the developer does all of it, you are paying developer rates for admin work.
Where the time actually goes
People picture the build as the whole job. It is not. A migration runs in phases, and the coding is only one of them. There is discovery and planning, where you agree what is moving and what gets dropped. There is the content model, deciding how your content is structured so it is not a mess to edit later. There is the front-end build. There is data migration and cleaning. There is testing, redirects and SEO checks so you do not lose your rankings on launch day. Then there is launch and the nervy week afterwards where you fix what only real traffic reveals.
The build gets the attention, but discovery and testing are where projects are quietly won or lost. Rush the planning and you pay for it in rework. Skip the redirects and SEO checks and you can tank the search traffic you spent years earning, which I have watched happen to sites that migrated in a hurry.
A realistic shape for the timeline
I will not give you a single number, because it would be a lie dressed as reassurance. But the shape is useful. A small, clean site with few integrations is a matter of a few weeks. A typical small-business shop with real product data and a handful of integrations is more likely a couple of months of proper work, not days. A large or messy store, or one with heavy custom functionality, runs longer again and should. The honest signal is this: if someone promises to replatform a real shop in a week, they are either not migrating much or they are cutting the corners you will trip over later.
Where people waste money
The most common waste is rebuilding things nobody uses. Old sites accumulate pages, features and plugins that quietly do nothing. Migrating all of it faithfully means paying to carry dead weight to a new house. A good migration is partly a clear-out. The second waste is a bespoke design for a site that did not need one. The third is going headless at all when the current platform was fine, which I have talked clients out of more than once. Spending nothing is cheaper than spending well.
How to make it cost less without cutting corners
You have more control here than you think. Clean your content before it is migrated, because you are paying either way and it is cheaper to delete a thousand junk pages than to move them. Be honest about which features you actually use, so the build only covers what earns its place. Take on the content entry and testing in-house if you have the people. And phase it. You do not always have to move everything on day one. Getting the core across and adding the nice-to-haves later spreads the cost and the risk.
The honest bottom line
A headless migration costs what it costs because of your content, your integrations, and how custom you want it, not because of a fixed menu price. The time goes into planning and testing as much as building. The right way to get a real number is to have someone look at your actual site and scope it properly, the same way I did before I moved my own work off Magento, which I wrote about in this note. If you want to understand what a move would involve for a specific platform, I went through it in detail for a Shopify to headless migration and on the migration service page. And if you would rather just have someone give you a straight scope and a real number for your own setup, that is the kind of thing I help with.