Modernise legacy software

Look at two things: is the business logic still correct, and is the code understandable. If the logic holds and you still recognise your process in the system, redevelopment is almost always cheaper, because years of exceptions are baked in that nobody could fully write down again. If the logic itself is outdated, for example because your process now works differently, redevelopment mostly moves old assumptions to a new stack. The data structure matters too: a database design that no longer matches how you work becomes the brake on every new feature. That is why an engagement starts with an audit before that choice is made.

With the strangler approach we put a new layer around the old system and move function by function, with old and new running in parallel. Upside: small steps, low risk, quick first result. Downside: longer total timeline, temporarily maintaining two systems and sometimes a duplicated data layer. Switching in one go means building everything and cutting over at a single moment. Upside: no interim solutions and a shorter engagement on paper. Downside: the risk is concentrated in one evening and you find gaps only when everyone is working on it. Hybrid wins most often: the core in one go, peripheral modules phased. What decides is how much downtime your operation tolerates.

Signs that often appear together: one person who knows how it works and without whom nobody dares change anything, critical processes in an Access database or Excel with VBA macros, an application on PHP 5 or a 2012 .NET version that no longer receives security updates, a vendor that no longer exists or no longer responds, a hosting environment nobody dares to patch, and changes that take weeks because every adjustment breaks something else. Also typical: new staff need months to understand the system, and a web of spreadsheets grows beside it to do what the system cannot.

Four types of engagement come up most. Existing web applications on an outdated stack, moving to a modern architecture while preserving functionality and data. Desktop software that needs to move to the browser, so people are no longer tied to one workstation and installs disappear. Spreadsheets and Access solutions that have effectively become business critical and need a real application with roles, validation and history. And monoliths split into clearly bounded services, usually not because separate services are a goal but because one component needs to scale independently or ship more often.

Migration is usually the largest and certainly the most underestimated part. We start with profiling: what is actually in the database, including duplicate records, empty mandatory fields and meaning that ended up in free-text fields. Then comes field-level mapping, a test migration on a copy and comparisons on counts and totals. For the transition, old and new run in parallel, initially read-only in the new system. The real cutover is planned for a quiet moment, with a delta migration for whatever changes during the switch and a fallback we have tested beforehand. Downtime therefore usually stays within a window of a few hours.

In the engagements we run, payback usually lands between twelve and eighteen months, and it rarely comes from savings on licences or hosting. Most of it sits in costs that appear on no invoice today: hours of manual retyping and checking, onboarding new staff that takes months, customer questions that cannot be answered quickly, revenue you leave on the table because a feature is technically out of reach, and the risk of a system without security updates. Before the audit we ask you to estimate those items roughly. Without those numbers, any modernisation business case stays a matter of gut feel.

That is often the smartest start. We begin where the pain is, for example the module that stalls daily or the screen your people work in most, and leave the rest standing for now. The condition is that new components talk to the old system across a clear boundary, so you do not end up with two half-connected systems. The upside is a spread investment and quick results where the return is highest. The downside is a longer total timeline and temporarily maintaining two environments. We say that upfront, not halfway through.

That is the rule rather than the exception. We then work from the outside in: first capture what the system does for users by watching your people work, then read the code and database to find where the rules actually live, and write down the assumptions we find in readable documentation. Logs, database contents and even old emails help with questions like why a particular exception exists. What we do not do is quietly optimise away odd behaviour, because odd behaviour often turns out to be a customer agreement. That documentation also ends your dependence on one person.

Modernisation succeeds or fails with the people working in it every day. So we involve several daily users from the start, not just the client, and deliberately keep frequent actions close to what people know; a new interface does not have to mean every way of working changes. Before the cutover, people can try things in a test environment with real data. At go-live we provide short work instructions per role, one or more sessions and extra availability in the first week. Where the process genuinely changes we say so explicitly and practise it, instead of hoping users figure it out.

No. Redevelopment is often cheaper because proven business logic and data survive, but not always. With code nobody can follow, a large share of the budget goes into working out how the current system behaves, and then a new build on a fresh specification can come out lower. It also holds that the further the existing data structure sits from the desirable one, the more expensive the migration. So after the audit we deliver an honest comparison of both routes with costs, risks and timelines, even when the conclusion is that building new is the better choice.

Those first four weeks matter most. We set monitoring and error alerting tighter than normal, watch performance on the heaviest screens and track whether background jobs and integrations complete cleanly every day. We also keep a short line to your users, because the first weeks always surface things no test finds: a report someone runs monthly, an export to the accountant, an action that only occurs at year-end close. Small corrections are picked up immediately in that period. The old system stays available for reference during those weeks, usually read-only.

Plan on one to three weeks of audit, then three to nine months for the engagement itself depending on size, number of integrations and the state of the data. With a phased approach the first modernised component is usually in use within six to ten weeks while the rest still runs on the old system. What influences the schedule most is not the building but the unknowns: undocumented rules, data quality and the availability of people who can explain how something is supposed to work. We name those risks in the audit with a range rather than a single date.

Handover is a period, not a moment. An engagement includes aftercare in the first weeks, documentation and a handover to whoever takes over management, whether that is your own team or another party. After that you choose: a retainer where we handle monitoring, security updates, dependency maintenance and further development, or availability on call for questions and incidents only. Because the code, infrastructure and documentation are yours, that is a free choice and not a dependency. In practice the first year after a modernisation is often busier than expected, because changes that were impossible for years are finally within reach.