Replatform or Redesign? Testing Whether the CMS Is the Problem

The replatform vs redesign question comes down to one test: is the content management system itself stopping the business, or is the problem in the design, content and structure sitting on top of it? If the platform is the bottleneck, a new look will not fix it. If it is not, moving to a new CMS spends a large budget to rebuild the same weaknesses somewhere else.

This guide looks only at that test. It sets out the three places a platform usually causes real pain (the editor, integrations and licence or hosting cost), how to gather evidence for each, and how to decide before anyone signs a migration contract. For the wider choice between a light refresh, a redesign and a full rebuild, see our guide on matching the fix to the problem.

Replatform vs redesign: what each one actually changes

A redesign changes what visitors see and how they move through the site: layout, visual style, navigation, page templates and often the copy. The underlying CMS, database and hosting usually stay the same.

Website replatforming changes the engine. Content, users, media, URLs and integrations move from one system to another, for example from an ageing custom CMS to WordPress, from WooCommerce to Shopify, or from a monolithic store to a headless setup. A replatform almost always includes some redesign; the reverse is not true.

Test one: is the editor the real problem?

Editor complaints are the most common reason teams ask for a new CMS, and the most often misdiagnosed. The pain frequently comes from how the site was built, not the platform.

Signs the platform is at fault

• The CMS cannot support structured content you need, such as reusable product specifications, locations or team profiles, without custom code for every change.
• Bilingual content is bolted on, so Arabic and English versions drift apart and cannot be managed side by side.
• There is no workable approval or role system, so marketing, legal and product teams all need developer help to publish.
• The vendor no longer updates the system, or the developers who built it are no longer available.

Signs the build is at fault

• Every page is a one off layout in a page builder, so editors fight spacing instead of writing.
• Fields are badly named or missing, so content gets pasted into a single large text box.
• Nobody was trained, and there is no documentation for the templates.

How to prove it

Ask two or three regular editors to complete the same five tasks they do every month, such as publishing a news post, updating a service page, swapping a banner and adding a page in both languages. Time each task and note where they need help. Then ask a developer who knows the platform whether each blocker could be removed by reconfiguring templates and fields. If most can, redesign with a better content model instead of migrating.

Test two: do integrations break because of the platform?

Integrations are where platform limitations tend to be real. A site may connect to a CRM, an ERP, payment gateways, booking tools and analytics, and some platforms make every connection a custom project.

Questions to answer with evidence

1. List every system the site must exchange data with, now and in the next two years. Include planned changes such as moving to Microsoft Dynamics 365 or Odoo.
2. Check what the current platform supports: maintained plugins or apps, a documented API, webhooks, and whether those are still updated.
3. Record actual failures: orders that did not sync, leads that went missing, manual exports someone runs every week.
4. Ask whether a middleware layer could solve it. Sometimes a small integration service between the site and the CRM removes the pain without touching the CMS.

No supported route to systems you depend on, plus workarounds that keep breaking, is strong evidence for replatforming. Poorly configured but workable integrations just need fixing.

Test three: is the cost of the platform rising faster than its value?

The third trigger is money. Licence renewals, paid extensions, specialist hosting and the developer time needed to keep an old system patched all add up. Compare what you spend to run the current platform each year with what it would take to run a likely alternative, then set that against migration cost.

What drives migration cost

• The volume and messiness of content, including media, product data and old posts that need cleaning before they move.
• The number of integrations that must be rebuilt and tested.
• Bilingual content and right to left layouts that must be recreated accurately.
• URL changes and the redirect mapping needed to protect search visibility.
• Training, documentation and a period of running both systems.

For a clearer picture of where project hours go, our breakdown of website development cost in Dubai and the overview of website cost by project type explain how agencies build an estimate. The most accurate quote comes from a short discovery phase that inventories content and integrations before anyone commits to a number.

Scoring the evidence before you decide

Put the findings from all three tests in one scorecard. It keeps the decision honest and makes agencies easier to brief.

If most rows point one way, the decision is clear. If they split, redesign on the current platform now and plan a migration later, building templates so they can move.

Hypothetical example: a Dubai trading company wants a new CMS because publishing product updates takes days. The editor test shows that every product sits in one long unstructured text box. The platform supports custom content types, so the team rebuilds the product templates during a redesign and publishing time drops sharply. No migration was needed.

Hypothetical example: an Abu Dhabi clinic group runs a custom CMS whose original developer has left. It cannot connect to the new booking system, and security patches have stopped. Here the platform is the problem, and a CMS migration is justified.

If you do replatform, protect what already works

A migration should not cost the search visibility, content or data that the current site has built up. Plan these from the start:

• URL inventory and redirects: list every indexed URL and map each one to its new address. Google's guidance on moving a site with URL changes recommends server side permanent redirects from old URLs to new ones.
• Content audit: decide what moves, what is merged and what is retired before export, not after.
• Integration testing: run real orders, enquiries and bookings through every connection before launch.
• Personal data: if customer records move between systems, check how the UAE Personal Data Protection Law, or the DIFC or ADGM rules where they apply, affect storage and transfer, and confirm with counsel.
• Editor training: schedule it before go live so the team is not learning under pressure.

If the decision lands on a redesign instead, the related question of template or custom design is the next one to settle.

Get a second opinion on your platform

Codeeo has delivered 200+ projects across the UAE and the US, and the team works on both sides of this decision: redesigns on existing platforms and site migrations to WordPress, Shopify, WooCommerce or headless setups. A website audit is a practical first step to test the editor, integrations and running cost before committing budget. Where WordPress is the likely destination, see our WordPress development service.

Because the office is in Dubai, UAE teams can walk through the findings with us in person. Contact Codeeo to talk through your current platform.