Case study
Modernizing Legacy Systems in a Regulated Industry
How to decide what to modernize first when you work somewhere every change has to be approved, recorded, and audited.
- Enterprise architecture
- Angular
- Power Automate
- Agentic AI
- Regulated industries
The brief
- Client
- Regulated enterprise — insurance / financial services (not named)
- Sector
- Enterprise architecture / platform strategy
- Scope
- Deciding what to modernize: screens, workflows, and where AI actually fits
- Role
- Principal architect and strategy lead
- Team
- Architecture, platform engineering, and compliance — working within the existing approval process rather than around it.
- Dates
- 2026 · method tested on a live migration
What this covers
- 3questions to answer, in order
- 1rule that overrides all three
- 2 in 1a real migration and a reusable method
- 0company or system names disclosed
The problem
Old systems in regulated industries rarely break. They just get slow to change.
In a regulated industry, every change to a system has to be reviewed, approved, and recorded. That process exists for good reasons. But over ten or fifteen years it shapes the software around it. Teams pick safe, familiar technology. Changes get bundled together, because each release costs paperwork. The result is a system that is very stable and very slow to change.
None of that is a failure. The system works. Policies get issued, claims get paid, audits pass. The problem turns up somewhere else: a change that should take a week takes three months, and it becomes obvious when a competitor ships something in a quarter that would take you a year.
There are usually three warning signs. Fewer engineers want to work on older technology, so the team gets harder to hire for every year. Release cycles are too slow to react to a rule change or a competitor. And a surprising amount of daily work is people manually moving information between systems, because there was never time to automate it.
This case study is about how we decided what to change — and, just as importantly, what to leave alone. The company and the systems are not named. The method is the part worth sharing.
How we broke it down
Modernizing is not one decision. It is three.Most teams treat it as one big project. That is why they either change nothing, or change too much in the wrong place.
Three questions, and one rule
1. What do people see and use?
The screens, and the framework they are built in. This is the easiest part to change and the part everyone argues about longest. The useful question is not which framework is best. It is which one your current team can work in quickly, and which one will still be supported in ten years.
2. How does the work actually get done?
The steps a piece of work goes through, and how much of that is still someone copying information by hand. This is where most of the daily cost sits. Low-code tools are excellent for simple, predictable processes and a poor fit for complex ones where every step needs testing.
3. How much should software decide on its own?
Where AI tools fit. They are genuinely useful for work that does not follow fixed rules, like reading documents that are never laid out the same way twice. They are not a good reason to replace a process that already follows clear rules and works.
The rule that beats all three: can it be audited?
Being able to show exactly what happened and why is not one feature to weigh against others here. It is a requirement. Any option that makes it harder is not a cheaper option, it is not an option. This ruled out more choices than cost and timeline combined.
The part most people forget: can you hire for it?
The best technology on paper is the wrong choice if it takes a year to find people who know it. This gets treated as a minor point in technical discussions, and then quietly decides how well the system is looked after five years later.
Approach
How we worked through it
Four steps, run inside the existing approval process rather than around it.
List what you have, and what is actually a problem
We went through every screen, workflow, and connection and sorted each one into: needs rebuilding, needs automating, needs AI, or needs nothing. That last group was bigger than anyone expected. Plenty of old software works perfectly well and just looks dated. Replacing that is spending money to feel modern.
Rebuild one thing first, all the way
We picked one representative part of the system and rebuilt it completely before touching anything else. The test was not whether it looked better. It was whether the audit trail and the accessibility still worked afterwards. Once that was proven once, the rest became a repeatable job instead of a risk.
Automate the boring work first
We started with the most predictable processes — the ones where everybody already agrees what the steps are. That is partly about building confidence. The compliance team needs to watch automation work on something low-risk before they will approve it somewhere that matters.
Add AI last, with the limits set first
AI tools were only used for work that does not follow fixed rules, and only in a role where they suggest something and a person approves it. The approval step was built in from the first day, not added later when a review asked where it was.
Decisions
- Which front-end framework should the rebuild use?
- Options: Angular · A React-style alternative · Stay on the existing stack
- Chosen: Angular
- The alternative is more popular and easier to hire for in general, and that is a real cost we accepted. We chose Angular for three reasons specific to this situation: the team already knew it from earlier work, its structure holds up better when several teams work in the same codebase for years, and its accessibility tooling lowered the risk of the rebuild breaking a compliance requirement. A team with different skills should reach a different answer here. Anyone who gives every company the same answer is not really answering the question.
- Low-code tools, custom code, or AI for the workflows?
- Options: Low-code for everything · Custom code for everything · AI everywhere
- Chosen: All three, matched to the work
- There is no single right tool, and picking one for everything is the most common mistake we saw elsewhere. Simple, predictable processes went to low-code tools, which build them in a fraction of the time. Complex, high-risk processes stayed in custom code, where each step can be tested on its own. AI was used only where the work genuinely varies every time. The question is always what shape the work is, not which tool is currently fashionable.
- How much should AI be allowed to do without a person?
- Options: Suggest only · Act on its own within set limits · Act freely, reviewed afterwards
- Chosen: Suggest only; a person approves
- Letting AI act on its own within set limits is technically possible today, and we chose not to. The tools for proving what an AI system did and why are newer than the confidence people currently have in them, and here you have to be able to explain every decision after the fact. So AI drafts and suggests, and a person signs off anything with a compliance consequence. That limit can be relaxed later, as the evidence gets better.
What it looks like
The recommendation
Treat it as three decisions, not one big project — check each one against whether it can be audited, prove the approach on a single part of the system first, and make sure every stage can be undone.
- Judge each framework on your team, not on popularity
- If it cannot be audited, it is not an option at any price
- Rebuild one part completely before committing to the rest
- Match the tool to the shape of the work, not to the trend
- Use AI only where the work genuinely varies each time
- Build the approval step in from day one
- Work inside the approval process; exceptions cost more later
Outcomes
- Proven once, then repeatedThe approachtested on one module before scaling
- Still intactAudit trailnothing lost in the rebuild
- Suggest, not decideWhat AI is allowed to doa deliberate limit, not a gap
- Works on other systemsReusethe method is not specific to this one
This one does not come with a single headline number, and it would be dishonest to invent one. What it produced is a way of deciding that held up against real rules and real technical limits, tested on an actual migration rather than argued in a slide deck.
The same three questions apply to the next old system that needs this treatment. The answers should come out differently, and that is the point. A different team, different rules, and a different hiring market lead somewhere else. A method that always gives the same answer is not a method. It is just a preference with extra steps.
There is no single right modernization plan. There is only the one your team, your rules, and your workflows can actually support.