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.