Migration and modernization

Software migration and modernization services rehearsed before cutover

We move websites and applications to new platforms, new versions and new hosting. Each move is practiced on a copy, checked against the source and reversible until you approve it.

  • 500+ WordPress projects delivered
  • Rehearsed on a copy first
  • Old URLs redirected
What is included
  • Replatforming
  • Version and framework upgrades
  • Legacy modernization
  • Data migration
  • SEO-safe URL changes
  • Hosting and infrastructure moves
Get a free quote Reply within one business day. NDA on request.
The problem

Why migrations get postponed

Nobody migrates for fun. The PHP version on the server is no longer supported, the framework stopped getting security fixes, the hosted platform changed its terms, or the one developer who understood the old system has gone. What holds people back is fear of the move itself: lost orders, broken logins, a drop in search traffic, a weekend of downtime that turns into a week.

Those fears are reasonable, and each has a specific answer. We rehearse the data move until the counts match. We map every old URL to a new one before launch. We run old and new side by side where the business cannot afford a hard switch. The method was shaped on WordPress, where we have delivered 500+ projects, and it carries over unchanged to Moodle, Laravel, CodeIgniter and plain PHP systems.

  • Running on unsupported versions

    The host is warning that the old PHP version will be switched off. The application throws errors on the new one, and the framework or plugins it depends on were last updated years ago.

  • Data nobody fully understands

    Ten years of orders, users and custom fields sit in tables with cryptic names. Some records are duplicated, some are orphaned, and no document describes what the columns mean.

  • Search rankings at stake

    The site earns its traffic from pages that have been indexed for years. A new platform means new URLs, and a careless launch can cost that traffic within days.

  • No room for downtime

    Customers order, learners take exams and staff log in at all hours. There is never a quiet week, so the switch has to happen without anyone outside noticing.

What we do

Kinds of move we carry out

Migration and modernization cover several different jobs. We scope yours as one of the following, or a combination, and plan the data, the URLs and the cutover for each.

Replatforming

A move from one system to another, for example a hosted site builder to WordPress, another LMS to Moodle, or a custom cart to WooCommerce, with content, users and history brought across.

Version and framework upgrades

PHP, framework, CMS and LMS upgrades that have been put off for several releases, done in steps on a branch with deprecated code fixed and each step tested.

Legacy modernization

Old applications brought under version control, covered with tests and restructured piece by piece, so adding a feature stops being a gamble.

Data migration

Repeatable import scripts with field mapping, cleaning and deduplication, run several times against fresh copies and reconciled against the source by count and by sample.

SEO-safe URL changes

A crawl of the old site, a redirect map from every old address to its new one, preserved titles, canonicals and sitemaps, and monitoring in Search Console after launch.

Hosting and infrastructure moves

Server, cloud or host changes with DNS, SSL, email, cron jobs and file storage accounted for, and a tested path back to the old environment.

Typical projects

Moves we are hired for

01

An end-of-life PHP application

A system written for an old PHP release made to run on a supported one, with dependencies updated, deprecated calls replaced and a test suite added along the way.

02

From a hosted platform to your own

Content, products, members or courses exported from a subscription service and rebuilt on software you control, including the customer accounts and purchase history.

03

Merging several sites into one

Regional or acquired sites with overlapping users and content consolidated into one install, with duplicate accounts merged by rule and every retired domain redirected.

04

A phased rewrite of a core system

A back-office application replaced module by module, with old and new sharing a database or syncing through an API until the last screen is retired.

In depth

Rewrite, upgrade or modernize in place

Three routes, and how we pick one

An upgrade keeps the application and raises what it runs on. It is the cheapest route when the code is sound and merely behind, as with a CodeIgniter 3 to 4 upgrade or a long-delayed Moodle release jump. Incremental modernization keeps the system live while we add tests, replace the worst modules and clean up the structure. It suits software that still fits the business but has become risky to change, and it is the subject of our legacy PHP modernization page. A rewrite or replatform starts fresh. We recommend it when the data model itself is wrong, the platform is a dead end, or the old code cannot be tested at all. Rewrites are the most tempting option and the most often regretted, so we ask for evidence before proposing one.

Rehearse, reconcile, cut over

Migration scripts are code, kept in the repository and run many times. The first rehearsal against a copy of production always fails somewhere: a date in the wrong format, a user with two accounts, a product with no category. We fix the script, not the data by hand, and run it again. After each run a reconciliation report compares source and target: row counts per table, totals for money columns, and a random sample of records opened side by side. Cutover happens only when a full rehearsal passes cleanly and we know how long it takes.

Cutover day and the way back

For most sites the switch is a short freeze. Writes stop on the old system, a final delta import runs, checks are repeated, and DNS or the load balancer points to the new one. Where a freeze is impossible, the two systems run in parallel for a period, with changes synced between them and users moved in groups. In both cases the old system stays intact and reachable until you sign off, so going back is a decision and not a rescue operation.

Keeping search traffic through a URL change

Before launch we crawl the old site and pull the pages that earn visits and links from analytics and Search Console. Each gets a permanent redirect to its closest new equivalent, never a blanket redirect to the home page. Titles, headings, structured data and canonical tags are carried over, and a new sitemap is submitted on launch day. Then we watch crawl errors and rankings for several weeks and fix stragglers. The platform-specific steps for a WordPress migration are covered separately.

Process

The path from audit to switch-off

  1. 1

    Audit and inventory

    We list the code, plugins, data, integrations, cron jobs and URLs in the current system, and flag what is unused and can be left behind.

  2. 2

    Route and plan

    Upgrade, modernize or rebuild is decided with you. The plan sets out the data mapping, redirect map, freeze window and rollback steps.

  3. 3

    Build and rehearse

    The target is prepared on staging and the migration scripts are run against fresh copies until the reconciliation report is clean.

  4. 4

    Cut over

    At an agreed quiet time we freeze, run the final import, repeat the checks, switch traffic and keep the old system on standby.

  5. 5

    Watch and retire

    We monitor errors, logins, payments and search crawl for the following weeks, then archive and switch off the old system when you approve.

Deliverables

Proof you get after the move

  • An inventory of what was moved and what was retired
  • A reconciliation report comparing source and target data
  • A redirect map covering every old URL
  • A rollback plan that was tested before cutover
  • Supported versions, with the code in your repository
FAQ

Migration worries and straight answers

Should we rewrite our old system or modernize it step by step?
Modernize step by step unless there is a clear reason not to. Incremental work keeps the business running, delivers improvements sooner and spreads the risk. A rewrite is justified when the platform is a dead end or the data model is wrong, and we will show you why before recommending it.
Will we lose data during the migration?
You should not, and the reconciliation report is how we prove it. Every rehearsal compares record counts, financial totals and sampled records between the old and new systems. The old database is kept untouched until you have checked the result yourself and signed off.
How much downtime should we expect?
For most projects it is a short maintenance window at a quiet hour, sized by the timed rehearsals. Systems that cannot pause are moved with a parallel run, where both versions stay live and users are switched over in groups. The plan states the window before you commit.
Will our search rankings survive a platform change?
They usually hold when every indexed URL is redirected to a matching page and the content, titles and structured data are carried across. We cannot control search engines, so we do not guarantee positions. We do monitor crawl errors and traffic after launch and fix anything that slips.
Can users keep their passwords?
Often, yes. Where the old system stores password hashes in a format the new one can verify, we carry them over and upgrade them quietly at the next login. Where it cannot, users get a planned reset email with clear instructions instead of a surprise lockout.
Do you migrate between learning platforms?
Yes. Courses, users, enrollments, grades and completion records can be moved between LMS products, and SCORM packages can usually be imported again as they are. The detail for Moodle is on our Moodle migration page.
What makes a migration expensive?
Custom code and data quality, far more than size. A large site on standard features moves quickly. A small one with years of hand-edited records, undocumented customizations and integrations that must be rebuilt takes longer. The audit at the start exists to find these before the quote.
Start a project

Tell us what you are moving and why

Share the current platform, its version and what worries you most about the move. You will hear from us within one business day, and the consultation and quote are free.

  • Free consultation and quote
  • NDA on request
  • You own the source code
  • Reply within one business day
Add budget and timeline optional, helps us quote faster

This form is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.