Website redesign vs replatforming.

Separate the customer problem from the technology problem

A website redesign changes what visitors see and how they understand, navigate, and act. It can include positioning, information architecture, content, visual design, interaction, and conversion paths. Replatforming moves the website to a different CMS, commerce platform, framework, or hosting architecture.

The two are often bundled because a new design may be hard to implement on the old system. But they solve different problems. A confusing offer is not fixed by moving databases, and an unsupported platform is not made maintainable by new colours and layouts.

Redesign without replatforming when the foundation still fits

Keep the platform when it can support the required pages, components, editing workflow, integrations, performance, accessibility, and future roadmap without excessive workarounds. Preserving it can reduce migration scope, retraining, data risk, and operational disruption.

Before committing, prototype the most demanding parts of the new experience. Confirm that the current system can support them cleanly and that technical debt will not turn routine changes into custom development. A refresh may be enough if the structure and platform are sound and the problem is limited.

Replatform without a full redesign when operations are the constraint

A business may need safer software, easier publishing, better product management, lower operational complexity, or integrations the current platform cannot support. If customers already understand and use the experience well, preserving familiar page structures and visual patterns can narrow the project.

This is still not a copy-and-paste exercise. Content models, URLs, forms, data, search behaviour, permissions, analytics, redirects, and third-party services must be mapped. Rebuilding the same interface on a different system can expose assumptions that were never documented.

Change both when experience and operations are holding the business back

A combined project can remove legacy constraints and avoid paying to reproduce an experience already due for replacement. It also creates the largest concentration of risk: new journeys, content, templates, data, tools, workflows, and infrastructure may all change around one launch.

Control that risk by defining requirements before selecting the platform, inventorying content and integrations, assigning data owners, prototyping critical workflows, and rehearsing migration. Use staged approvals and a release plan with backups, validation, and rollback decisions. The content migration guide covers the editorial side of the move.

Make the decision with evidence

• Customer experience: are visitors failing because of message, structure, content, or interaction?
• Editorial work: can the team publish safely and efficiently?
• Technical fit: can the platform support required features, integrations, security, accessibility, and performance?
• Economics: compare migration cost with the cost of continuing to work around limitations.
• Risk: identify data, URL, integration, training, and launch dependencies.
• Roadmap: choose for credible future needs, not every hypothetical feature.