Replatforming From Drupal, AEM or .NET Without Downtime

Website replatforming without downtime is possible when the new site is built and loaded in parallel, content is kept in step with repeated delta syncs, and the switch happens at the DNS or routing layer with a tested way back. Moving off Drupal, Adobe Experience Manager (AEM) or an ageing .NET build is rarely risky because of the target platform; it is risky because of the cutover. This playbook covers how to choose the target, how to run the content migration, and how to plan the final hours so visitors, editors and search engines barely notice the change.

Why legacy platforms get replaced, and why the move goes wrong

Most organisations do not replatform for fun. The usual triggers are a platform version reaching the end of vendor support, licence renewals that no longer match how the site is used, a shrinking pool of developers who know the old stack, or an editorial team that has given up on the authoring experience. Drupal 7 is a common example: the Drupal project lists its end of life as 5 January 2025, and teams still running it should confirm the current support position on Drupal.org before deciding between an upgrade and a move.

The failures tend to follow the same pattern. Content is exported once, months before launch, and the live site keeps changing. Redirects are written from memory instead of from crawl data. Integrations with CRM, search or single sign on are discovered late. Every one of those problems is a planning gap, not a technology gap.

Before any of the steps below, run a proper inventory. Our guide on what to audit before rebuilding an enterprise website covers the content, integration and analytics checks that feed directly into a migration plan.

Choosing the target: a decision matrix for website replatforming

The three realistic destinations for most UAE organisations leaving Drupal, AEM or .NET are WordPress, a headless setup (a content management system feeding a separate front end such as Next.js), or a custom build. None is right for everyone. The table below compares them on the criteria that usually decide the matter.

Questions that settle the choice

• Who edits the site every day? If it is a small marketing team, the authoring experience matters more than the architecture diagram.
• How many channels consume the content? A website plus an app plus kiosk screens points towards headless.
• How much of the current site is really an application? Calculators, portals and account areas built in .NET may need a custom service even if the marketing pages move to a CMS.

Hybrid answers are common. A typical pattern is marketing pages on WordPress or a headless CMS, with account features kept as a separate custom application behind the same domain.

Platform specific traps when leaving Drupal, AEM or .NET

Drupal migration

A Drupal migration usually involves content types with many fields, taxonomies used for both navigation and filtering, and views that build listing pages on the fly. The views are the trap: they are not content, so they do not appear in an export, yet visitors and search engines rely on the URLs they produce. List every view backed page and decide how the new platform will rebuild it. Paragraph style components also need mapping to the new block or component model, field by field.

AEM migration

An AEM migration involves pages built from components and templates, assets in the DAM with metadata and renditions, and content often organised into language copies and live copies. Export the component inventory first and count how often each component is used; rarely used components can often be merged. Check asset rights and metadata before moving files, because a DAM often holds images that are licensed only for specific uses.

Custom .NET sites

Older .NET sites frequently mix content and code: text held in database tables, resource files or even hard coded in page templates. Expect to write extraction scripts rather than relying on an export feature. Authentication, form handlers and scheduled jobs often live inside the same application, so map every server side function and decide where it will run after the move.

Content migration with delta syncs

A zero downtime migration depends on one idea: the old site stays live and editable for as long as possible, and the new site catches up with it repeatedly rather than once. That is what delta syncs do.

Step 1: map the content model

Write a mapping document that lists every source content type, each field, the target type and field, and any transformation needed (for example, splitting a single body field into structured blocks, or converting relative links). Agree it with the editorial owners before writing scripts.

Step 2: build a repeatable migration script

The first full load should come from a script, not a manual copy. The script must be safe to run again and again: it should create new items, update changed items and skip unchanged ones, using a stable source identifier stored on each migrated item.

Step 3: run delta syncs on a schedule

After the first full load, run the script regularly against the live source, picking up only items created or modified since the last run. Most platforms record a modified timestamp; where they do not, compare content hashes. Log every run: items created, updated, failed and skipped.

Step 4: handle deletions and media

Deltas often miss deletions. Keep a list of source identifiers and compare it on each run so removed pages are unpublished on the new site too. Media needs the same care: copy files, keep alt text and captions, and rewrite every reference in body content to the new media URLs.

Step 5: shrink the content freeze

Because the new site is only ever a short delta behind, the editorial freeze before launch can be very short. Many teams freeze only on the final day, run one last delta, check it, and go.

Preserving search visibility through the move

Downtime is not the only way a replatform hurts. Lost rankings are slower to notice and harder to recover.

• Crawl the old site first. Export every indexable URL, its title, meta description, canonical and status code. Add URLs from analytics and search console data so you capture pages that are linked externally but missing from navigation.
• Keep URLs where you can. The cheapest redirect is the one you never need. If the new platform can match the old path structure, use it.
• Map redirects one to one. Send each old URL to its closest equivalent with a permanent redirect. Avoid sending everything to the home page.
• Carry over metadata and structured data. Titles, descriptions, hreflang for English and Arabic versions, and schema markup should all be migrated, not rewritten from scratch on launch day.
• Test on staging. Run the full redirect list against the staging site and check every response before launch, then again after.

If your team wants a second pair of eyes on this stage, the technical SEO review is designed for exactly this kind of check.

The cutover playbook

The cutover is a sequence, not a moment. Write it down, assign an owner to every step, and rehearse it on staging at least once.

Two weeks before

• Lower the DNS time to live on the records that will change, so the switch propagates quickly and a rollback does too.
• Confirm SSL certificates are issued and valid for every hostname on the new hosting.
• Agree the launch window. For many UAE businesses a quieter period is late evening or a weekend morning; check your own analytics rather than assuming.
• Freeze code on the new site except for launch fixes.

Launch day

1. Start the short content freeze on the old site and announce it to editors.
2. Run the final delta sync and check its log for failures.
3. Run smoke tests on the new site: key templates, forms, search, login, payment or booking flows, and the top pages by traffic.
4. Switch traffic by changing DNS, the load balancer or the CDN origin. Routing at the CDN or load balancer is usually faster to reverse than DNS.
5. Run the same smoke tests on the live domain, then the redirect list.
6. Confirm analytics, tag manager and consent tools are firing on the new site.
7. Lift the freeze and let editors work on the new platform.

The first week after

• Watch server errors, not found reports and form submissions daily.
• Submit the new XML sitemap and monitor indexing.
• Keep the old platform running read only, with backups, until the rollback window closes.

A rollback plan you can actually use

A rollback plan is only real if it has a trigger, an owner and a tested procedure. Agree all three before launch.

The data reconciliation line is the one most often missed. If the new site accepted enquiries for two hours before a rollback, those leads must not disappear. Route form submissions to the CRM and an email inbox in parallel during launch week so nothing depends on a single path.

Hypothetical example: a professional services firm in Abu Dhabi moves from a custom .NET site to WordPress. During rehearsal the team finds that the old site's document library sits behind Windows authentication. Instead of delaying launch, they keep that one path routed to the old server through the CDN for a further month, launch everything else, and migrate the library separately. The rollback plan covers both routes.

Integrations, hosting and security checks

Integrations are where hidden scope lives. List every connection the old platform makes or receives: CRM and marketing automation, search, payment gateways, single sign on, translation services, analytics, and scheduled exports to other teams. For each one, record who owns it, how it authenticates, and how it will be tested before launch.

Hosting deserves the same attention. A new platform on underpowered hosting will feel slower than the legacy site it replaced, however well it is built. Our article on the hidden risk of cheap hosting for corporate websites explains what to look for.

Running the project with an agency

Replatforming projects often go out to tender. If you are running a formal process, our guide to running a web agency RFP in the UAE explains how to frame requirements so suppliers price the migration work honestly rather than only the new design. Ask every shortlisted supplier to describe their delta sync approach, their redirect process and a rollback they have actually carried out.

Internal readiness matters as much as supplier choice. Name a product owner, secure time from editors for content checks, and make sure IT can make DNS and firewall changes on the night. The checklist in enterprise website readiness covers these preparations in detail.

Plan your replatforming with Codeeo

Codeeo designs and builds websites on WordPress, headless architectures with Next.js, and custom platforms, and handles the move from legacy systems as part of that work. The team can review your current Drupal, AEM or .NET estate, recommend a target, and plan the migration and cutover with you. Codeeo has delivered more than 200 projects across the UAE and the US, has a team of 80+ across Dubai, Riyadh and Karachi, and UAE clients can meet the team in person at the Dubai office.

Explore site migration, WordPress development and Next.js developers, or see the wider web development service. When you are ready to talk through your platform, contact Codeeo.