Platform migration
Migrate your website to an environment you can maintain.
We move blogs, business websites, e-commerce systems and portals from platforms that have become expensive or difficult to operate. The migration covers the content, editing and connected services, with security exposure and running costs assessed before choosing the replacement.
Find out what the old platform is responsible for
An existing site holds more than the pages in its menu. It may also handle customer accounts, order history, publishing permissions, scheduled jobs and integrations that the business depends on. A replacement has to account for that work.
We begin with an inventory and compare the available routes. A publishing site may be suitable for static delivery with a separate editor. A shop or portal may need application services. The decision includes migration effort, ongoing maintenance and the exposure of the proposed system.
Platforms and content we migrate
WordPress, Joomla and Drupal are common starting points. Older and custom systems need an inspection of their data and behaviour.
WordPress
Posts, pages, taxonomies, media, users and plugin-owned data, including historical URL patterns.
Joomla
Content held in extensions, databases and media trees, mapped to explicit fields in the replacement.
Drupal
Content types, custom modules and publishing workflows. Compare staying on Drupal with moving away.
Custom sites and hosted platforms
For custom PHP, static HTML, Wix or Squarespace, we establish what can be exported, retained or rebuilt before quoting.
From inventory to launch
You review the inventory and proposed architecture before the replacement is built.
- 01
Inventory and export
Record reachable and historical pages, content, assets, forms and application behaviour. Identify data that needs special handling.
- 02
Model the content and functions
Define where each part will live and how editors will manage it. Account for accounts, checkout and integrations where they are needed.
- 03
Build and test the replacement
Use Astro for content delivery or PHP where application logic is required. Test publishing and connected services before switching traffic.
- 04
Launch and follow up
Test the redirect map, agree the cutover and recovery arrangements, then review logs for missed addresses. Scope ongoing maintenance for the new system.
| Area | CMS runtime | Static publishing architecture |
|---|---|---|
| Public delivery | Application code produces pages on request | A build produces files before a visitor requests them |
| Editing | Usually inside the public CMS | In a separate editor connected to structured content |
| Updates | CMS core, extensions and runtime remain operational concerns | Build dependencies and separate dynamic services remain operational concerns |
| Recovery | Database, media and configuration backups | Repository, assets, configuration and deployment backups |
| Handover | Depends on access to the CMS and its extensions | Repository, content, accounts and build instructions transfer together |
Keep the links people already use
Search results, bookmarks and external links can point to pages no longer visible in the navigation. We collect those addresses from the sources available and map each valuable URL to its destination before launch.
Our article on building and testing a migration redirect map explains the process, including what a crawl misses and what to monitor after release.
Built before launch
From the available URL sources, not only the current menu.
Tested as data
Each mapped address has an expected destination that can be checked against staging.
Maintained after launch
Logs are reviewed for missed addresses and valuable redirects are kept in place.
Content, editing and continuity
Will my URLs change?
Some can stay exactly as they are; others may need explicit redirects. The inventory records the important current and historical addresses and assigns each one a destination before launch.
Will I lose my editor?
No. You get a browser editor with fields for the content the site actually contains — headings, images, links and page sections — plus a preview.
What about my contact forms?
Forms are inventoried with the rest of the site. On a static build they submit to a small endpoint rather than the CMS; notification, validation and spam controls are tested before launch.
I have a shop. Can you move that?
Sometimes. A catalogue with a checkout can move; subscriptions, complex tax rules or deep integrations may make improving the existing shop the safer option. That decision belongs in the audit.
My site is multilingual.
That is supported. The inventory takes longer because each language and its URL relationships need to be accounted for, and stale translations often need an editorial decision.
How long does it take?
A small content site commonly takes several weeks. The useful estimate comes after the inventory because distinct page types, languages and integrations matter more than the raw page count.
What does it cost?
The audit is a fixed fee and produces a written plan and build price. You decide whether to proceed after reading it.
Can I go back?
The old site remains available until launch and you retain its export. You also own the new repository, content and accounts.
Planning a move from an existing platform?
Send the URL, platform name and the functions the business depends on. Include current hosting and maintenance costs if you have them.