We Rewrote a 12-Year-Old System With the Wrong Team: the 7 Steps I Use to Hire for Legacy Modernisation in Singapore

The system was twelve years old, nobody enjoyed working on it, and the decision to modernise was correct. What was wrong was the hiring. We recruited an architect, then four strong engineers to build the replacement, and eleven months later the new system still could not reproduce the output of a nightly reconciliation job that existed in a single stored procedure and that nobody, including the person who wrote the original specification, knew was doing arithmetic corrections. The engineers were good. The sequence was wrong. Here are the seven steps I use now, in order, before a single requisition goes out.

Step 1: Classify the system before you write the advert

Legacy modernisation is four different projects wearing the same name, and they need different people. Before writing anything, put your system in one of these four categories.

Retire. The system has fewer users than you assume and the functionality exists elsewhere. The hire here is nobody. Audit usage first, because a surprising number of modernisation projects are funded for systems that three people use quarterly, and nothing is cheaper than discovering that before you recruit.

Encapsulate. The system works and is stable, but nothing can integrate with it. You are not modernising the core, you are putting a documented interface in front of it. This is a smaller, more senior, shorter engagement, and it is often the correct answer for something that is ugly but reliable.

Replace incrementally. The system is actively holding back delivery and must change while it stays in production. This is the common case and the one the rest of this article is about.

Rewrite. The runtime or platform is genuinely unsupportable and encapsulation is not possible. Rare, expensive, and the hardest hiring profile, because you need people who have finished one, which is a much smaller group than people who have started one.

The classification determines the advert, the seniority and the band. Writing a single generic modernisation advert and hoping the right candidates self-select is how you end up interviewing architects for an encapsulation job and encapsulation specialists for a rewrite.

Step 2: Hire the archaeologist before the architect

This is the correction that came out of our eleven months, and it is the most important step here.

Your first hire is a senior engineer whose first deliverable is a description of what the current system actually does. Not a design for its replacement. Observed behaviour, documented from the running system: the data flows, the scheduled jobs and what they modify, the validation rules that live in the database rather than the application, the integrations that are not in any diagram, and the behaviour that is clearly unintentional but that something downstream now depends on.

Legacy systems are full of that last category. A nightly job that silently corrects bad data. A rounding behaviour that a finance report has been reconciling against for years. A validation rule that exists only in a stored procedure, which is exactly what cost us most of a year. An architect hired first produces a clean target design that accounts for none of it, and the gap surfaces during cutover, which is the most expensive possible moment to discover it.

Six to eight weeks is a realistic deliverable window for a system of moderate size. The output is unglamorous and it is the foundation of everything after it. The architecture work that follows is then grounded in the system you have rather than the one in the documentation.

Step 3: Retain the incumbent engineer, deliberately and in writing

Somewhere in your organisation is the person who still understands the old system. They may not be senior, they may not be the most polished engineer you have, and they are the single most valuable input to this project.

The failure pattern is so consistent it is almost a law. A new team arrives to replace the system this person has maintained for years. They read that, correctly, as their expertise being written off. Within a few months they leave, and the only reliable source of behavioural knowledge about the system leaves with them, usually just as the first cutover approaches.

Prevent it explicitly, and before the new hires start rather than after. Name them as the knowledge owner for the migration with a defined scope: reviewing the behaviour documentation, and signing off each seam cutover. Allocate real time to it instead of expecting it on top of their existing workload. Compensate it as the specialised contribution it is. And be straightforward about the end state, because if their role changes when the old system retires, an unspoken plan is read as a bad one, and in a market with short notice periods they will act on that reading quickly. Our guide to having direct conversations with engineers about their role covers the mechanics of that discussion, which is uncomfortable and much cheaper than the alternative.

Step 4: Screen for incremental migration, not for the stack

Here is where most adverts go wrong. They list the legacy technology and the target technology and ask for both. That filter mostly selects for people who have worked in both ecosystems, which is nearly irrelevant to whether they can move a live system from one to the other.

The requirement to screen for is a worked example of an incremental migration completed in production, most commonly a strangler pattern where new code gradually intercepts and replaces paths through the old system, or a parallel run where both systems process the same input and results are compared before the switch.

And then press on the specifics, because this is where designed-but-never-delivered experience shows up:

1. How did traffic actually move from old to new? Listen for routing at a specific layer, percentage ramps, per-customer or per-tenant cohorts.
2. How did you verify the new path matched the old one? Strong answers describe shadow traffic and automated result comparison, including what they did about the differences that turned out to be the old system being wrong.
3. What was the rollback, and did you ever run it? Anyone who has done this has executed one, and will tell you what they learned when it did not work first time.
4. How did data stay consistent while both systems were live? This is the question that separates the field. Dual writes, change data capture, reconciliation jobs, and an honest account of the window where things could diverge.

Candidates who have genuinely done this answer in operational detail and usually volunteer the story of what went wrong during cutover, because something always does. Candidates who have only designed migrations stay fluent through question one and get vague at question four, every time.

Step 5: Test the reverse-engineering skill on your own code

Modernisation work is mostly reading. An engineer on this project will spend far more time understanding existing code than writing new code, and that is a distinct skill that standard interviews do not test at all, because standard interviews ask candidates to write.

So test it directly. Take a real module from your own system, anonymise the names if you need to, pick something genuinely gnarly of eighty to two hundred lines, and give it to the candidate with two questions: what does this do, and what would you want to verify before changing it?

What you are looking for is not whether they understand it immediately, because the whole point is that it is hard to understand. You are looking for method. Strong candidates narrate a strategy: they look for the entry points, they ask what calls this and what it writes to, they identify the parts they are confident about and explicitly flag the parts they are not, and they ask about production behaviour rather than guessing. Weak candidates either declare it bad code and propose a rewrite, or claim to understand all of it, and both responses are disqualifying for different reasons.

This exercise has a second benefit: it is an honest preview of the work. Candidates who find it tedious rather than interesting are telling you something useful, and it is far better to learn it now. The general framing for this kind of evidence-based screening is in our piece on interviewing developers against an inherited codebase.

Step 6: Staff the seam, not the stack

When teams plan modernisation headcount, they plan for building the new system. The new system is the easy part. The failures happen at the seam, the boundary where old and new coexist, and that boundary needs explicit ownership rather than being everyone’s shared edge.

Concretely, the seam is: data synchronisation in both directions, dual writes and what happens when one side fails, reconciliation that detects divergence before a customer does, traffic routing and the ability to move it back, and a consistent view for users who are hitting both systems in the same session. Every one of these is a real engineering problem, none of them appears on the target architecture diagram, and in my experience they account for most of the schedule overrun on these projects.

For a team of four, I would now allocate roughly two engineers to the seam, one to new functionality and one shared with the incumbent system, which is close to the inverse of how we staffed the project that failed. If you are assembling this capacity with external help, our guide to standing up an offshore engineering team from Singapore covers the delivery mechanics, and the seam ownership question becomes even more important when the team is distributed.

Step 7: Write a first ninety days that ships a seam

The last step is a plan, written before the offer goes out, whose ninety-day target is one narrow slice of functionality moved to the new system and serving real production traffic, with a tested rollback.

Not a completed design document. Not a proof of concept. One real slice, chosen for being low-risk and genuinely live. Pick something read-only if you can, with a small blast radius and a clear correctness check.

This matters for three reasons. It proves the whole pipeline works, which is the only thing that actually de-risks a modernisation: the routing, the data sync, the comparison, the rollback, end to end. It gives the organisation a visible result within a quarter, which is how these projects keep their funding past month fourteen. And it tells you quickly whether your hiring was right, while the decision is still cheap to correct.

What this costs, and why the sequence saves money

The uncomfortable part of this method is that step two looks like paying a senior engineer for two months to write documentation, and that is a hard line item to defend to a finance function that wants to see the new system being built.

The arithmetic is worth doing out loud. Six to eight weeks of one senior engineer is a fraction of a quarter of team cost. The alternative, which is what we did, was four engineers working for eleven months against a target design that did not reflect the actual system, and then rediscovering the real behaviour one surprise at a time during integration. The documentation phase is not overhead on the project. It is the cheapest possible version of work you will otherwise do at four times the headcount under schedule pressure.

The second saving is in the band. Once you have classified the system, you often discover you need fewer senior people than a generic modernisation plan assumes. An encapsulation job genuinely is one senior engineer for a quarter. Only the forced rewrite needs the scarce, expensive profile of someone who has finished one, and knowing which situation you are in before you negotiate is worth more than any sourcing tactic. For broader market context, our walkthrough on hiring senior developers in Singapore covers the general band and process.

One last thing I would tell anyone starting this. Decide early what you are not going to migrate, and write it down. Every legacy system has parts that are stable, boring, understood and genuinely fine, and the instinct to modernise them because they are old is the instinct that turns a two-quarter project into a two-year one. The best candidates will ask you this question in the interview. That is a very good sign.

Frequently Asked Questions

Should I hire for a full rewrite or an incremental migration in Singapore?

Incremental in almost every case, and the hiring consequence is what makes the difference concrete. A full rewrite requires the organisation to fund two systems simultaneously, maintain feature parity against a moving target, and absorb a single high-risk cutover, which in practice means a team that stays fully staffed for the entire duration with no deliverable until the end. Incremental replacement, usually via a strangler pattern where new functionality intercepts and gradually replaces the old paths, lets you hire a smaller team, deliver value within a quarter, and stop at any point with a working system. The honest exception is a system whose runtime or platform is genuinely unsupportable, for example a language runtime with no security patches and no migration path, where encapsulation is impossible and the rewrite is forced. Even then, hire for incremental delivery of the rewrite rather than for a single release, because a two-year project with no intermediate milestone is how modernisation budgets get cancelled in month fourteen.

Who should be the first hire on a legacy modernisation project?

A senior engineer whose first deliverable is a description of what the current system actually does, not a design for what will replace it. I call this the archaeologist role and it is the single highest-leverage hire on the project. The reason is that every modernisation failure I have seen traces back to a target architecture built on assumptions about current behaviour that nobody verified, and legacy systems are full of behaviour nobody intended: a nightly job that silently corrects data, a validation rule that exists only in a stored procedure, an undocumented integration that one department depends on. An architect hired first will produce a clean design that does not account for any of these, and the gap surfaces during cutover when it is most expensive. Hire the archaeologist, give them six to eight weeks to produce observed behaviour documentation, and the architecture work that follows will be grounded in the actual system rather than an idealised one.

How do I keep the engineer who understands the old system?

Make their role in the modernisation explicit, paid and time-boxed before the new hires arrive, and never frame the project as replacing their work. The failure pattern is predictable and common: the one person who understands the legacy system watches a new team arrive to replace it, correctly reads this as their expertise being written off, and leaves within a few months, taking the only reliable source of behavioural knowledge with them. The fix is to name them as the knowledge owner for the migration, with a defined scope such as reviewing the behaviour documentation and signing off each seam cutover, allocate real time to it rather than expecting it on top of their existing work, and compensate it as the specialised contribution it is. Be straightforward about the end state too. If their role changes when the old system retires, say so early and agree what they move onto, because an unspoken plan is read as a bad one and in a market where notice periods are short they will act on that reading quickly.

What should I ask in a legacy modernisation interview that a normal interview misses?

Ask for the cutover story rather than the architecture. Most senior candidates can describe a target architecture competently, and it tells you very little, because the architecture is the easy part of modernisation. Instead ask them to walk through a migration they personally completed in production and then press on four specifics: how traffic moved from old to new, how they verified the new path produced the same results as the old one, what the rollback procedure was and whether it was ever executed, and how data stayed consistent while both systems were live. Engineers who have done this answer in operational detail, usually with a story about the thing that went wrong during cutover, because something always does. Engineers who have only designed migrations answer in diagrams and become vague precisely at the dual-write and reconciliation questions. One more question separates the top candidates: ask what they decided not to migrate, because knowing which parts of a legacy system to leave alone is the judgement that keeps these projects finishable.

William

Talent Sourcing Expert at HireDeveloper.sg. Sources and screens engineers for Singapore employers, with a focus on the roles that keyword filters miss: migration specialists, reverse-engineering strength and the people who can prove a system behaves as claimed.