Should we change CMS at the same time as the redesign, or do the two separately?

Rebuild the front end on the CMS you already have. Prove the new design works with real traffic. Move platforms later, when the design is a known quantity and the only variable is where the content lives.

The exception is a CMS that genuinely blocks the work. If the design cannot be built or edited in it, or the platform has a hosting or security deadline you do not control, the move goes first and the redesign waits behind it.

Bundling them looks efficient because both jobs touch content. It is not efficient. A redesign changes what a page says and shows. A replatform changes where that content lives and who can edit it. Run them together and every problem at launch has two possible causes.

Traffic drops 30% in the week after launch. Was it the new page structure, or the redirect map from the migration? Both changed on the same day, so nobody can say.

The same ambiguity hits smaller things. An editor cannot get an image to sit where it did in the mockup. Is the component wrong, or is the new content type missing a field? The answer takes a day to find instead of ten minutes.

In our projects, separated work has one suspect per problem. That is the entire argument. It is worth more than the few days of overlap you save.

Answer these yourself, in writing, before you send a brief. They decide the sequence, and they stop a supplier deciding it for you.

Is the current CMS blocking the design, or just annoying to use? Blocking means the layout cannot be built, or a key piece of content has no field to live in. Annoying means the editor is slow and ugly, and the site survives another year on it. Most complaints we hear are annoying, not blocking.

Who edits the site weekly, and what do they get stuck on? If the honest answer is that nobody has edited it since last year, the CMS is not your problem and moving it will not pay for itself.

How many pages do you have, and how many are worth keeping? Migration cost scales with pages kept, not pages owned. A 400-page site where 60 pages still earn traffic is a 60-page migration and a deletion exercise.

What breaks if URLs change? Answer this before choosing a platform. Some CMSs impose a URL shape. If your top-earning page is /guides/pricing and the new platform wants /resources/guides/pricing, you own a redirect for every URL and a temporary ranking dip.

Three orders are defensible. Pick by which condition you actually meet, not by which is fastest.

• Design first, move later. The safe default. New front end on the existing CMS, live for a few months, then a platform move with a design you already trust.
• Move first, then design. Right when the CMS blocks the work: no flexible page structure, no way to edit key content, or an end-of-life date on the hosting.
• Both at once. Defensible for a small site, five or ten pages, or when the old platform is being switched off on a date you do not control. It survives on three conditions: the content set is frozen before build starts, one person owns every decision, and the old site stays reachable so you can roll back.

Migration is not export and import. It is deciding what to keep, rewriting what stays, and mapping old fields to new ones. That work is done by your team, not the studio, and it is where combined projects slip.

Estimate it with three counts. Count the pages worth keeping. Count the distinct content shapes among them, a blog post, a case study, a product page, a legal page. Everything else is deletion work, which is fast but still needs a decision per URL.

A worked case. A 180-page site, 40 pages worth keeping, four content shapes. The four shapes are the real build: four content types in the new CMS, four templates. The 40 pages are content entry, and if the copy is being rewritten too, that is 40 writing jobs sitting on one marketing lead. The other 140 pages are a redirect spreadsheet. Quoted as “migrate 180 pages” this looks enormous. Counted properly it is four shapes, 40 entries and a spreadsheet.

Note what happened there: the page count barely mattered. A template is a page design, not a page. Six templates can drive hundreds of URLs.

The cheapest fix is often a tidier set of content types plus an hour of training. If your editors are stuck because one page type has 40 optional fields and no guidance on which to fill, that is a configuration problem. Reducing it to eight fields with clear labels costs a fraction of a replatform and removes the same frustration.

So test the complaint before you pay for a platform. Watch the person who edits weekly do one real update. If they get stuck on a badly named field, fix the field. If they get stuck because the thing they need to change is hardcoded and no field exists, that is blocking, and you have your answer.

Some studios prefer the bundled project because it is larger, longer and harder to leave halfway through. That is not a conspiracy, it is an incentive, and you should price it in when a supplier says the two jobs are cheaper together.

A platform recommendation from a studio that resells that platform, holds a partner badge or builds only in it is not neutral advice. Ask directly what else they considered and why they ruled it out. A good answer names a trade-off. A weak answer names a feature list.

Then ask the lock-in questions. Can you export all content in a usable format? Do you own the repository and the deployed site? Is hosting billed to your accounts or theirs? At Glasspage the client owns the design, code, repository and deployed site from day one, and everything deploys to their own accounts, so the honest test is whether your supplier will say the same in writing.

Bring these answers with you. Suppliers quote better against decisions than against questions.

1. Blocking or annoying: one sentence on what the current CMS makes impossible.
2. Weekly editors named, and the specific thing each gets stuck on.
3. Page count kept, and page count being deleted.
4. Content shapes among the kept pages, listed.
5. Whether URLs must change, and who owns the redirect map.
6. Any date you do not control, such as hosting end-of-life or a licence expiry.
7. Your chosen sequence, and the condition that justifies it.

Every Glasspage engagement includes a CMS the client’s team can edit safely, built on Payload, so a redesign with us involves a platform decision whether or not the client came looking for one.

When someone arrives already halfway into a platform move, we ask for the frozen content set first. Foundation is the first of four milestones, and content structure is settled during it rather than argued about during page deployment. If the content set is not frozen, we say so before quoting, because a moving content set is what turns a three-week marketing site into something longer.

And if the honest read is that the existing CMS is fine and the design is the problem, that is the smaller job, and we would rather quote the smaller job than sell the bundle.