Should You Redesign While You Replatform?

Only as a deliberate decision, not a default. A redesign makes sense when there's a documented, specific problem with the current design — not just because you're already touching everything. Bundling a redesign into a replatform without discussing the tradeoff is one of the most common sources of scope creep and budget overrun.

Last verified: September 6, 2026.

When a redesign genuinely makes sense alongside a replatform

• A documented conversion problem tied to specific design elements, with data behind it — not a general feeling the site looks dated
• A brand identity change already planned and scheduled, independent of the platform decision
• Known, specific usability issues with clear evidence: session recordings, user testing, support ticket patterns

What those three have in common is that the redesign would be justified on its own, this year, even if no platform change were happening. That's the test. A change worth making anyway is worth sequencing alongside a migration; a change that only became attractive because a migration is underway is scope arriving through the side door.

When it doesn't

• "We're already touching everything, so we might as well." This treats design change as free when it's adding real scope, risk, and testing surface to an already complex project.
• No specific documented problem — just a general sense the site could look better.
• A stakeholder wants visible change. A replatform is largely invisible from the outside, which creates real pressure to produce something people can see. That's a communication problem, and a redesign is an expensive way to solve one.

The honest tradeoff to discuss explicitly

Testing surface. A UX review now has two variables — platform and design — instead of one. Every conversion difference after launch has two candidate explanations, and no clean way to separate them.

Timeline risk. Design iteration cycles don't compress the way engineering estimates sometimes can. A round of stakeholder feedback takes as long as it takes, and it sits on the critical path in a way most engineering tasks don't.

Diagnosis after launch. If conversion drops, was it the platform or the redesign? With both changing at once, the honest answer is that you can't know from analytics alone — which means the fix is guesswork, and guesswork during a revenue dip is expensive.

None of this means never bundle them. It means the decision should be made with these tradeoffs stated plainly, not assumed away, and that someone should be able to articulate what the redesign is for beyond "we were already in there."

The middle path most teams should consider

A visual refresh is not the same thing as a redesign. Carrying the existing information architecture, navigation structure, and checkout flow across unchanged while updating typography, color, and component styling preserves the thing that actually drives conversion — the structure a returning customer already knows — while still producing a site that doesn't look like the old one.

That option resolves most of the pressure a redesign was meant to relieve, at a fraction of the risk. It's worth putting on the table explicitly before the conversation becomes binary.

True Botanicals is the case for doing the design work deliberately and measuring it: a re-theme followed by 200+ A/B tests took conversion from 4.1% to 6.2%. That's a design program with evidence attached, which is a different thing from a redesign bundled into a migration because the project was already open.

If you do bundle them

Two things become non-negotiable. First, pre-launch UX testing matters more, not less, because there's no post-launch way to tell platform effects from design effects. Second, agree in advance which parts of the current experience are explicitly out of scope for redesign — checkout is usually the right answer — so the highest-risk surface changes on one axis rather than two.

It's also worth reading website redesign vs. CRO on whether a redesign is the right lever for a conversion problem at all, independent of the platform question.

How to sequence a redesign after the replatform

If the answer is "yes, but not now," the sequencing matters. The usual mistake is treating the redesign as a phase two that never gets scheduled, which is how a team ends up bundling it next time out of frustration.

A workable order: replatform first with the existing design carried across; stabilize for 30 to 60 days, which is long enough for the funnel to produce a clean post-migration baseline; then run the redesign as its own project against that baseline, with the platform as a known quantity rather than a second variable.

The gain is diagnostic, and it's substantial. A redesign measured against a stable baseline can be evaluated — you know what moved and why. A redesign measured against a migration cannot, because both changed at once and no amount of analysis separates them afterwards.

Having the conversation internally

This decision is rarely settled by the technical argument, because the pressure behind a bundled redesign is usually organizational. A replatform is expensive and largely invisible from outside, which makes it hard to point at when someone asks what the money bought. A redesign is the visible thing, and that is a genuine need rather than vanity.

Two ways to meet it without absorbing the risk. Show the internal audience what the replatform actually delivers — release velocity, the roadmap items now possible, the operational work that stopped being manual — so the project has a story that isn't a screenshot. And put a scheduled, funded design phase on the roadmap immediately after stabilization, so "not now" reads as a sequence rather than a refusal.

If the decision still lands on bundling, that's a legitimate call made with the tradeoffs visible, which is all this framework asks for.

Where this fits

Redesign scope creep is the second of the four consistent causes in why replatforms go over budget, and the decision sits inside Anatta's replatforming method.

Frequently Asked Questions

Should I redesign my site during a replatform?

Only if there's a specific, documented reason — a real conversion problem, a scheduled brand change, or documented usability issues. "We're already touching everything" isn't itself a good reason.

What's the risk of bundling a redesign with a replatform?

Added testing surface, timeline risk, and a harder-to-diagnose launch, since there are now two variables — platform and design — changing at once and no way to separate their effects from analytics alone.

Is there a middle option between keeping the design and redesigning it?

Yes, and it's the one most teams should consider: a visual refresh that keeps information architecture, navigation, and checkout flow unchanged while updating typography, color, and component styling. It relieves most of the pressure at a fraction of the risk.

If we do bundle a redesign, what should stay out of scope?

Checkout, in most cases. It's the highest-risk surface and the one where a conversion regression costs the most, so changing it on one axis rather than two is worth the discipline.

If we don't redesign now, when should we?

After the replatform has stabilized for 30 to 60 days, so the redesign runs against a clean post-migration baseline. Measured that way it can actually be evaluated; measured against a migration it cannot, because both variables changed at once.

What's the real reason redesigns get bundled into replatforms?

Usually organizational rather than technical. A replatform is expensive and invisible from outside, so a redesign becomes the visible thing to point at. That's a genuine need — meet it by showing what the replatform delivers and scheduling a funded design phase after stabilization, rather than by absorbing the risk.