Migration from a legacy custom engine to a supported platform

I move live sites off hand-written engines that nobody supports any more. The picture is usually the same: the code was put together years ago for one narrow task, the person who wrote it is long gone, every small change costs days of guessing, and the database holds years of real content that cannot simply be typed in again. My work is to carry that content and that behaviour onto a maintained platform — one with documentation, regular updates and more than one specialist in the world who can read it.

It starts with reading, not with writing. I go through the old code and the table structure and put together an inventory: which pages, forms, user roles and background jobs are genuinely in use, which tables are alive and which have been dead for five years. That inventory is agreed with you before a single record is moved. A rewrite made from memory always loses half the small things — a filter someone uses once a month, a letter that goes out on registration, a printable form the accountant depends on — so the inventory comes first and becomes the list we both check the result against. After that the data goes across with record counts compared table by table and relations verified, addresses and redirects are rebuilt so search traffic and old links keep working, templates and forms are ported, outdated libraries are replaced with supported ones, and settings are pulled out of the code into configuration where they belong.

I count the migration as complete when the numbers match and the content has been checked by sample — not at the moment the new site opens in a browser, because an empty page opens beautifully too. The old version and a copy of the database stay untouched until the end of the warranty period, so there is always something to compare against and somewhere to step back to. Your staff receive a written instruction and a live walkthrough, and the move itself is planned in stages, so the current site keeps serving visitors from the first day to the last.

What the work includes:
— reading the old code and the database structure, with a written inventory of what is really used and what is dead;
— data transfer with record counts reconciled table by table and relations between records checked;
— rebuilding addresses and redirects so indexed pages and external links do not break;
— porting templates and forms, including the validation and the letters they trigger;
— replacing outdated libraries with supported equivalents;
— separating settings from code, so environments stop differing by accident;
— an instruction and training for your staff, in plain language rather than developer shorthand;
— a staged relocation plan that keeps the site running the whole way through.