What happens to your content when your website moves?
A migration usually starts with a decision about something else. Your site is still on Drupal 7, which stopped receiving security fixes at the end of its life in January 2025. The licence on your current system is up for renewal, or the system was built in-house years ago and fewer people each year know how it works. Or 2 websites are being merged into 1.
Whatever the reason, your content has to come with you: years of pages, documents and images, and the web addresses other sites have been linking to all that time. Moving it by hand is slow, and afterwards it's hard to tell whether everything arrived.
A scripted migration makes the move repeatable, so we can run it, check what arrived, fix what's wrong and run it again as many times as it takes before your new site goes live.
How we run a migration
Every migration follows the same 5 steps, and your current site stays live until the new one takes over.
1. We start with a site audit
A site audit shows what your site holds and where the content can be read from: a database, an export, an API, or only the public pages. It sets out your options and what each would take before you commit.
The audit also counts what's there. When we counted a policy institute's website to plan moving it into a university's main site, more than half of its items turned out to be attached files, the papers themselves.
2. We map your content to its new home
Next we work out where each kind of content will live on the new site, from content types and fields to categories, media, users and menus. Most of a migration's decisions are made here, so we make them with you, including which types to merge and what to leave behind. Nexus, a free tool we built, shows the content model as a diagram you can explore with your editors.
3. We build the migration and rehearse it
The migration is code, written with Drupal's Migrate API, which is the part of Drupal built for bringing in content from other systems. Where its standard plugins can't handle your content, we write our own. We run the migration again and again against sanitised copies of your current content, so gaps and mapping mistakes show up while there's time to fix them. Your editors keep publishing in the old site meanwhile, and each run picks up their changes.
Sometimes the facts you need are buried in free text, such as dates or names inside old page bodies. With your approval, and under our Responsible AI policy, we can use AI to pull them out into proper fields. Fixed rules handle what they can and AI works through the rest, with a person reviewing anything the AI was unsure of. Every extracted value keeps a link to the text it came from, and we check what the AI discarded as well as what it kept.
4. We check what arrived
We compare the migrated content with the source to find anything missing or misplaced, using automated checks where we can. Your team then reviews it on a test copy of the new site, a section at a time. The new site also gets automated tests, like everything we build.
5. We launch
Close to launch, we agree a short content freeze with you, run the migration a final time, check the result and switch over.
What you get
Besides your content in its new home, you keep the plan and the code behind the move.
A content map
It records what your current site holds and where each part lives on the new one, including what was merged and what stayed behind. Your editors and developers both work from it.
The migration code
The migrations live in your site's repository, built on Drupal's Migrate API, along with the checks that compare what arrived against the source. By launch day, they've been run many times.
Redirects for your old addresses
Pages that people have bookmarked or linked to are redirected to their new homes, so those links keep working after launch.
Migrations we've worked on
A few, described without naming the clients:
- 2 public websites for a state government regulator, with a digital agency partner. Its published decisions carry legal weight, so the migration we designed matched documents against the regulator's records management system and kept the old web addresses working, right down to the home page. It could also be re-run safely, because it remembered which pages editors had unpublished.
- Around 20 years of a federal department's public content, moved onto GovCMS with a digital agency partner. The old system had no export, so the migration worked from the public pages. We built it as a separate project with its own custom code, and it delivered the content into a GovCMS SaaS site, where custom modules aren't allowed.
- Well over a decade of a community radio station's broadcast history, through a digital agency. We read it from a legacy system's API. The import stages the data and can resume after an interruption, and it brings the newest shows across first, so a partial run still leaves current content on the site. Every old track address gets a permanent redirect.
- Another community radio station moving off Drupal 7, through the same agency. Some of its pages kept their current text only in the old database's revision history. A routine clean-up of that database would have left those pages empty without anyone noticing, so the migration reads the revisions.
- A university whose website we've worked on for 9 years, through its move from Drupal 7 to Drupal 11.
What it costs
Every migration starts with a site audit, and the audit is part of the migration we estimate for you. Once it shows what has to move, we send you an estimate before any work starts.
When the scope is defined, we can give you a fixed-price quote, and that's the price you pay. The estimate or quote sets out what's included and what isn't, such as redirects or content you've decided to leave behind. Nothing starts until you've approved the scope and cost.
The cost depends mostly on the content:
- how many kinds of content there are, and how much they change on the way
- where it comes from, since a database or an export is quicker to work from than crawled pages
- how much cleaning it needs, including facts pulled out of free text
- how many documents, images and other files come with it
You can also choose AI-assisted delivery, which gives you the same tested quality for up to 30% less on suitable work. Writing migration code often suits it. Deciding what goes where stays with people, as does every review.
Where a migration leads
Once your content is on a current version of Drupal, later versions arrive as in-place Drupal upgrades. If you'd like us to host the new site, managed hosting covers moving it across, and a support plan keeps it up to date after launch. We've also written about streamlining Drupal migrations on our blog.
FAQs
Can you migrate from a system that isn't Drupal?
Yes. We migrate from custom-built and legacy systems as well as from older versions of Drupal, and where the old system has no export, we can work from its public pages.
We're on Drupal 8, 9 or 10. Do we need a migration?
Usually not. From Drupal 8 onwards, moving to the current version is an upgrade made in place, which our Drupal upgrades page covers. Sites on Drupal 7 need a migration, because Drupal 8 was rebuilt from the ground up.
Can you move just the content, or the whole site?
Either. Every migration moves content, and it can bring files, media, users, categories, menus and redirects with it. The site's features and design are built again on the new site, by us or by your own developers.
Will our site look the same afterwards?
That's up to you. The look comes from the new site's design, so we can rebuild your current design or design a new one and build that.
How long does a migration take?
It depends on how much content you have and how much it changes on the way. A small site can take a few weeks, and a large one with several sources can run over months. We agree a timeline with you once the site audit shows what's involved.
Can we do the migration in stages?
Yes, and we often do. The migration can run in parts, for example categories first, then content, then files, with a review after each stage.
What if our content is messy or inconsistent?
That's common on a site that has been running for years. We can clean and normalise content on the way, for example by correcting dates or tidying file names.
Do we need to freeze content while you migrate?
Only for a short time near the end. While the migration is being built, your editors keep publishing as usual, as long as the site's structure stays the same. Just before launch, a short content freeze lets the final run bring everything across.
