A Mortgage Origination Platform, Rebuilt on .NET With No Downtime Window
PHP to .NET 10 in roughly six to eight months, on a 3-tier structure, verified function by function against the running original.
A live mortgage platform, rebuilt underneath the business using it
Brokers were submitting live mortgage applications through it every working day. Underneath, the platform was PHP, and every change to it had become slower and riskier to make.
It is a large enterprise financial application: three separate lending journeys, with DIP and automated decisioning, affordability and product selection behind them, and numerous business rules, calculations and integrations across the mortgage journey. The platform is our client's product, and it runs in production at a UK bank.
AnAr's team rebuilt it, working as the client's engineering team. The platform now runs on .NET 10 with MVC in a 3-tier structure, with the lending rules in the service layer and the database platform unchanged. It went live in a single cutover in roughly six to eight months, verified against the running original and cleared by four layers of testing, with no downtime window taken by the business.
Start to go live, including functional additions.
Lending rules in one of them, the service layer.
Downtime windows taken by the business.
Of testing cleared before go-live.
Three things that made this harder than a language change
The hard part was never PHP to .NET. It was doing it underneath a live lending business, against rules where being subtly wrong is worse than being obviously broken.
The business could not stop
Brokers submit, underwriters assess, operations teams manage the cases, every working day on a live book. There was no window in which the platform could go dark while a replacement was stood up in its place.
The rules decide the outcome, so behaviour had to match
DIP and automated decisioning, affordability, and product eligibility by rate, LTV and expiry are not display logic. A rewrite that gets any of it subtly wrong produces a wrong lending decision, not a cosmetic bug. The acceptance bar was behavioural equivalence, not a feature checklist.
PHP to .NET is an ecosystem change
Not a framework upgrade and not a version bump. No libraries, patterns or page structure carry over. The database platform was the only constant across both sides of the rebuild.
A 3-tier structure, with the lending rules in one layer
The client names maintainability as the biggest improvement over the PHP original. This structure is the reason it is one.
Where the lending rules live now
The rebuilt platform runs on .NET 10 with MVC, in three tiers: view and controller, a service layer, and a data access layer over SQL Server. The lending logic lives in the service layer, so a rule change is a change in one layer rather than several.
The database platform stayed on SQL Server across the rebuild, so the data layer was not a second migration running inside the first.
Every lending journey rebuilt intact
All three lending journeys carried across the rebuild, each with its own rules and validations. DIP and automated decisioning, affordability across income, expenditure and commitments, and product selection by rate, LTV and expiry date all sit in the service layer now, rebuilt and verified against the running original.
View and controller, service layer, data access.
Each with its own rules and validations.
SQL Server, carried across unchanged.
What the rebuild delivered, and what it means in practice
The left column is what was built, stated plainly. The right is the client's own assessment of the difference, which is theirs to make rather than ours to measure.
What the rebuild delivers
Stated plainly, each one confirmed.
- Rebuilt from PHP onto .NET 10 in roughly six to eight months.
- A 3-tier structure with the lending rules in the service layer.
- SQL Server unchanged across the rebuild, so the data layer was not a second migration inside the first.
- All three lending journeys carried across, each with its own rules and validations.
- Behaviour verified function by function against the running original.
- Four layers of testing before go-live: manual, Katalon regression, K6 load and speed, independent third-party security.
- A single cutover, with no downtime window for the business.
- Functional additions shipped during the rebuild rather than deferred.
What it means
The client's own assessment.
- The client names maintainability as the biggest gain: the rebuilt application is easier for developers to read, troubleshoot and extend than the PHP original.
- The lending rules sit in one layer, so a rule change is made in one place.
- Future enhancements are a smaller job than they were, on a supported framework with current libraries and better integration capability.
- Brokers, underwriters and operations teams kept working through the switch.
The platform does exactly the same job it did before, for the same brokers, underwriters and operations teams. The difference shows up in what it now takes to change it.
A rewrite of this class is not mostly a language exercise
The rules are the product, the business cannot pause while they move, and the original has to stay up as the reference for the whole build. That is where the calendar time goes: four layers of testing, a function-by-function comparison against a running platform, and a cutover that has to be right the first time because there is no downtime window to fall back into.
AnAr Solutions has been building and modernizing production software since 2014. Twelve years, 150+ projects delivered, 95% client retention.
What the full case study covers:
- The rebuilt architecture, tier by tier, and where the lending rules sit
- How behaviour was verified against the running original
- The four testing layers, and what each one covered
- The full stack, before and after
The PDF lands in your inbox in a minute. You get the case study to read and forward internally, not a sales sequence.
The full write-up, including the architecture and the verification approach, as a PDF.
Carrying a legacy application that is getting harder to change? See Legacy Application Modernization →
Prefer to talk it through? Contact our team →
A team is slow to build and quick to lose
AnAr Solutions has been building software and running dedicated engineering teams since 2014. Twelve years, more than 150 projects delivered, and 95% client retention. Those teams are a large part of what the retention figure is made of.
A dedicated team takes years to become genuinely valuable to the company it serves, and that value is held in people rather than in a contract. AnAr's half of the arrangement is the half that is easy to get wrong.
What this virtual captive team case study covers:
- The composition of the account, and what the client chose
- The split in full: what stays with the client, what AnAr answers for
- How the account held together across eight years of changing roles
- The client's own testimonial, in full
The PDF lands in your inbox in a minute. You get the case study to read and forward internally, not a sales sequence.
The full write-up, including the client's testimonial, as a PDF.
Working out how to set up a team in India? See Team Solutions →
Want the mechanics of how a dedicated team gets built and run? See Your team in India →
Prefer to talk it through? Contact our team →