Drupal Relaunch: What Happens to Your Content and Old URLs?

By Greg Nowak. Last updated 2026-09-09.

Before you approve a Drupal relaunch, you should be able to trace an existing page through to its place on the new site. What happens to the text, images and translations? Where does the old link lead? Those answers belong in the project scope, while there is still time to resolve them.

Drupal CMS 2.0, released on 28 January 2026, introduced Drupal Canvas as its default editing experience and the first site template. The Drupal CMS 2.0 announcement gives teams fresh options for building pages. If you already have a website, you also need to work out how your existing content and its relationships fit those options.

The checklist below is a suggested way to agree what developers will deliver, what editors will review and what the person approving launch needs to see.

Decide what stays before mapping fields

Start with the content structure. Will you keep the existing content types, fields and relationships, or move material into a different structure? Record which parts are included. A single line for “content migration” in an estimate leaves too much open to interpretation.

A content register gives those decisions a home. For each item, or clearly defined group, record whether it will be retained, rewritten, merged or retired. Add an editorial owner and the intended destination. Leave unresolved decisions clearly marked: an empty destination field should never leave a developer guessing whether to discard the content.

Once those decisions are clear, map each source field to its destination. Specify any changes to the data and what should happen when a value is missing. An old article summary, for example, might become an introduction, fill a teaser field or go unused. Editors need to settle that choice before a developer applies it across the collection.

Ask to review a small sample early. Include ordinary pages and a few awkward ones: long articles, missing summaries, embedded downloads and translated material. Editors should approve how those examples look and behave before the team extends the rules to everything else.

Check the relationships as well as the text

A page review needs to cover more than its words. Does the intended image appear? Does the download open? Does the language switch take the visitor to the corresponding content? Give media and translations their own acceptance criteria, including captions, alternative text and publication status where relevant.

Drupal’s Migrate API provides an extract, transform and load framework. Source plugins retrieve data, process plugins transform it, and destination plugins save it. Map tables connect source identifiers to destination identifiers so later migrations can look them up. Dependencies let related migrations run in the appropriate order.

For your project, this means asking for a dependency plan that covers the relevant authors, categories, files, media and content. Have the implementer demonstrate the agreed translation relationships too. Make those connections visible in the review.

Separate the record check from the editorial check. First, reconcile what was imported against the agreed scope. Then inspect whether it means and does what it should. The sign-off should name the examples reviewed, the exceptions accepted and the person who approved them.

Give every old URL a deliberate outcome

Keep a URL register alongside the content register. Each old address needs an approved destination or removal decision, followed by a recorded test result. If the destination is still undecided, assign it to an editorial owner so the developer has a clear decision to implement.

Google’s site-move guidance recommends mapping old URLs to their replacements and using server-side permanent redirects, such as 301 or 308, that go straight to the final destination. Unrelated retired pages should not all lead to the homepage. Where there is no replacement, return an appropriate 404 or 410 response.

Drupal’s Redirect project offers manual redirect management and an API for loading, saving and deleting redirects. Its separate Redirect 404 submodule can aggregate requests for missing pages and help administrators create redirects from them.

Ask the team to show how the approved URL register becomes deployed redirect rules, then test the historical addresses against their intended destinations. Agree who will review exceptions and maintain the rules after handover. That test evidence should be part of the redirect deliverable.

Agree what you need to see before launch

Set the approval requirements before the final rehearsal. This suggested checklist gives each part of the work a reviewable result. Adapt the owners to fit your team.

Rehearse the migration and the editorial handover

Migrate API supports rolling back a migration, adjusting it and running it again. It also documents ways to track source changes. Validate these options against your content and editing workflow before relying on them for launch; the ability to rerun a migration does not establish how every change will be handled.

Use an agreed test copy for the rehearsal. Record the input, procedure, duration and exceptions found. Where appropriate, put corrections into the migration rules and repeat the affected checks. Any manual work that remains needs its own task and owner.

The gap between rehearsal and launch deserves particular attention. Editors need to know where to work, when changes must stop and how their final changes will reach the new site. Ask for a demonstration with a newly created item, an edited item and a withdrawn item, with an agreed expected result for each.

Decide who can pause the launch and what evidence would justify doing so. You also need an operational recovery plan covering the website, its data and editorial activity during the switch. Define that separately from the migration rollback procedure.

Keep someone responsible after launch

Google’s guidance also calls for updated internal links, canonical and applicable hreflang annotations, a new sitemap, and removal of development-only indexing blocks. It recommends testing redirects, monitoring Search Console and server logs, and keeping redirects for at least a year, generally longer where useful. Search visibility can fluctuate while Google processes the move.

Put this work on the schedule before launch. Name the person who will review findings, assign fixes and report progress. Agree which failures need immediate attention and which can go into the normal maintenance queue. Any exception accepted at launch should leave the meeting with an owner and a review date.

Greg can take on discovery, migration scripts and redirects, editorial coordination and the launch acceptance record through a GrN.dk engagement. Agree the scope around what you need in hand: approved mappings, repeatable migration instructions, test evidence and a monitoring plan. You will have a clear basis for approving the relaunch, with practical instructions for the team looking after it afterwards.

Related on GrN.dk

• Your AI Image Has Content Credentials. Will Your Website Keep Them?
• Google’s August 18, 2026 Content API Cutoff: Feed Cleanup Before Merchant API Migration
• Drupal 10's December 2026 Deadline: Start With the Upgrade Inventory

Need help with this kind of work?

Plan your Drupal relaunch with Greg Get in touch with Greg.

Sources

• Drupal CMS 2.0 is here
• Migrate API overview — Drupal
• Redirect — Drupal project
• How to move a site — Google Search Central