Migrating a regulated financial services platform off OutSystems in ten weeks sounds aggressive. The truth is, with the right scope, the right team, and an honest read on what to rebuild versus what to lift, it's not as dramatic as it sounds.
We talk a lot about migrations on this site, including how to do them without being precious about platforms. Here's a longer write-up of one of them. Finbridge agreed we could share the engineering side. The commercial side stays private.
The situation
Finbridge had been running on OutSystems for several years. The platform had done its job. It shipped the original product fast, kept the audit trail tight, and got the business through the regulated stages no founder enjoys. By the time we got involved, the product roadmap had shifted toward AI-native workflows, and the cost of building those inside the existing estate had become the thing slowing the company down.
We had two conversations before we agreed to take the work. The first was about scope and timeline, the second about whether moving was actually the right call. We told them — honestly — that OutSystems is still excellent for the workflows it was already running, and the right answer might be to migrate only the parts the new roadmap really needed.
After looking at it together, they decided to migrate the whole platform. Their reasoning was sound. Operating two stacks long-term added cognitive overhead they didn't want to carry, and they had a clear architectural direction for the AI layer that depended on owning the data plane.
What we did
Week 1, discovery
We mapped the surface area, applications, integrations, scheduled jobs, identity flows, audit hooks. We tagged each component as lift-and-shift, rebuild, or rethink. About 60% of the platform fell into “lift-and-shift”, same shape, new stack. The remaining 40% needed either a fresh rebuild (because the OutSystems shape didn't fit the new runtime) or a rethink (because we were going to change its job to support the AI workflows coming).
Weeks 2–3, foundations
Next.js, Postgres, infrastructure-as-code, OpenTelemetry, identity via the existing IdP, audit log parity. Nothing exciting, and that was the point. The new stack's foundation had to be observably equivalent to what OutSystems was already giving them, before we put a single user-facing feature on it.
Weeks 4–8, feature parity
We migrated the user-facing flows incrementally. Users were on a working application throughout, initially the old one, then progressively the new one as flows shifted across behind a traffic-routing layer. We modernised UX where the lift was cheap and visible. We deliberately deferred ornamental changes that would have lengthened the schedule without changing the outcome.
Week 6 onwards, the AI overlay
From week six we started layering AI features in. The document processing pipeline went first. Then the RAG-powered assistant. Then the prompt-to-query analytics. Each one shipped behind a feature flag and graduated as its eval suite passed. None of them blocked the migration timeline, and all of them were live within ninety days of go-live.
Weeks 9–10, handover
Documentation, runbooks, knowledge transfer to the client's team. We stayed available for the first AI feature iterations post-launch, but the goal was always for the platform to be operable without us.
What surprised us
- The lift was bigger than the integrations. We assumed integrations to bureaux, identity, and audit would be the long pole. They weren't. The long pole was user-facing flows where the original OutSystems implementation had “clever” behaviour buried in the platform's conventions. Re-expressing that cleanly on the new stack was where the time went.
- AI features were the easiest part. Once the stack was modern and the data plane was ours, adding RAG, assistants, and prompt-to-query was straightforward. The hard work had been the platform, not the AI.
- Users didn't notice the migration. They noticed the UX refresh. They noticed the new assistant. They didn't notice that the entire underlying stack had moved. That's how you want it.
“The hard work in a re-platform isn't the new stack. It's being honest about the old one, what was earning its keep, what wasn't, and what was hiding behind platform conventions you only see when you have to leave.”
What we'd say to anyone considering it
First, don't migrate as a gesture. If the platform is still the right tool, stay. Migration is justified when the platform's shape is genuinely blocking the work the business wants to do, not when there's a vague sense that something newer would feel better.
Second, get the scope right. A fully-scoped 10–12 week migration is enormously different from an open-ended “we'll see what we find” engagement. Discovery exists to make that scope honest.
Third, pick a partner who's comfortable telling you not to migrate. If everyone you're talking to is enthusiastic about the move, you're hearing what they want to sell, not what you need.
If you've got a platform decision in front of you and you'd like an independent read, that's exactly what our consultancy engagements are for.
