Most migrations that go badly went badly before anyone wrote a line of code. The build itself is rarely the hard part. The mess comes from decisions that nobody made, content nobody looked at, and access nobody chased up until the week it was needed. I have run enough of these to know that the projects that go smoothly are the ones where the client did a bit of homework first. So here is the honest, non technical list of what to sort out before you move to a headless setup, whoever ends up doing the actual work.
Take an honest inventory of what you have
You cannot move what you have not counted. Before anything else, get a real list of your pages, your products if you sell things, your blog posts, and any of the odd corners that have built up over the years. Most sites have far more than the owner thinks. Old campaign pages, three near identical about pages, a blog that stopped in 2021. Seeing it written down is usually the first time anyone has looked at the whole thing at once, and it changes the size of the job in either direction.
Decide what moves, what gets rebuilt, and what gets binned
Not everything deserves to come with you. A migration is the best chance you will ever get to throw away the pages nobody visits and the features you added once and never used. Go through that inventory and mark each thing as keep, rebuild, or drop. Keep is content that comes across roughly as it is. Rebuild is the stuff that needs rethinking because it was awkward on the old site anyway. Drop is the dead weight. Doing this early means you are paying to move a leaner, better site rather than carting the clutter across and tidying up later, which never happens.
Map every URL you actually care about
This is the step people skip and regret. Every page that has a decent search ranking or gets linked to from elsewhere has an address, and if that address changes without a redirect, the traffic to it can disappear. Before the build starts, pull a list of your current URLs, especially the ones that bring in visitors, and plan where each one lands on the new site. Where an address changes, you want a redirect from the old one to the new one. Get this right and a migration barely dents your rankings. Get it wrong and you spend the next three months wondering where your visitors went. I wrote separately about whether going headless hurts your SEO, and this redirect work is most of the answer.
Remember the site is more than pages
The visible pages are only half of it. Think about everything the current site quietly does. The contact form that emails you, the booking or payment flow, the newsletter signup, the reviews widget, whatever feeds your stock levels. Each of those needs a home on the new setup, and each is a small decision. Some you keep as they are, some you swap for something better, some you find you no longer need. The ones that catch people out are always the invisible ones, the integration with an accounts system or a supplier feed that only one person remembers exists. List them now, not when something stops working after go live.
Decide who is going to enter the content
Someone has to put the content into the new system, and that someone costs either time or money. This is one of the biggest swings in how much a migration ends up costing, so decide it deliberately. If your team does the content entry, it is cheaper but slower and needs a clear handover so they know how. If the developer does it, it is faster and tidier but you are paying for the hours. There is no wrong answer, but there is a wrong way, which is to leave it unspoken until the site is built and empty and everyone assumes the other person was doing it.
Gather your access before day one
Nothing stalls a migration like waiting on a login. Your domain name, your current hosting, your analytics, your email setup, any third party accounts the site talks to. Someone needs the keys to all of it, and on older sites those logins are often scattered across a former employee, an agency that no longer answers, and a personal email account. Chasing them down can take longer than the build. Round them up early, before the clock is ticking, so the switch over is a quiet afternoon rather than a scramble.
Agree what finished actually means
Write down, in plain words, what you expect to be true when the project is done. The old links redirect. The forms send email to the right place. Someone on your team can edit the site without calling anyone. Analytics is still recording. It sounds obvious, but a shared checklist is what stops a migration being called finished when it is only half done. It also gives you and whoever built it the same picture of success, which is worth more than any contract clause.
None of this is technical, and that is the point. The build is a job for a developer, but the preparation is a job for you, and the two together are what make a migration calm instead of chaotic. If you want a sense of the money and time involved once you have done this groundwork, I went through that in what a headless migration costs and how long it takes, and for the shape of the work itself there is what a Shopify to headless migration actually involves. I did all of this to my own work when I moved off Magento, which I wrote about in this note. If you would rather have someone walk through your own site with you before you commit to moving it, that is the kind of thing I help with.