--- title: "From OutSystems to AI-native, how we re-platformed Finbridge in 10 weeks" url: "https://www.doddledesign.co.uk/insights/finbridge-migration" section: "Insights" description: "What it actually looks like to move a regulated financial services platform off OutSystems onto a modern AI-native stack, including the parts that surprised us." published: "2026-04-21" publisher: "Doddle" --- Case notes # From OutSystems to AI-native, how we re-platformed Finbridge in 10 weeks 21 April 2026 9 min read 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. ![A heavy angular geometric form dissolving into pixels and reforming as a lighter open structure - the re-platforming itself, in abstract.](https://www.doddledesign.co.uk/images/insights/finbridge-migration.webp) 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. ![Finbridge Global platform](https://www.doddledesign.co.uk/images/work/finbridge/finbridge-dashboard.webp) Finbridge Global, post-migration. AI-native stack, OutSystems retired. ## 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](https://www.doddledesign.co.uk/services/consultancy-services) engagements are for. More from Doddle ## Keep reading. Practice ### “We've just hired an AI guy” - the eight questions to ask next Owning the IP and the roadmap is the right instinct. One enthusiastic person, a Copilot licence and a push straight to main is not a delivery model. The questions we ask when we walk into this, the answers we usually get, and what good looks like. 8 min read Practice ### The AI decisions that never make the demo - prompts, residency, tokens and fallbacks Prompt engineering, model residency, open-model experiments, paying for tokens versus hardware, and gateway fallbacks. The unglamorous engineering that decides whether production AI is affordable and dependable, drawn from the work we've been doing lately. 10 min read Case notes ### PayWise, two years on - what an OutSystems product looks like at maturity Zero incidents in two years. Ten thousand statements processed. A small team. Fixed operating costs. The honest, unglamorous case for what an enterprise low-code platform actually buys you over time. 7 min read ## Want to talk about this? We're always up for a conversation about the work, the patterns we're seeing, what's worked, what hasn't. No pitch deck. [hello@doddledesign.co.uk →](mailto:hello@doddledesign.co.uk) [Let's talk](https://www.doddledesign.co.uk/contact) ## More from Doddle - [Studio summary for agents](https://www.doddledesign.co.uk/llms.txt) - [Full text of every page](https://www.doddledesign.co.uk/llms-full.txt) - [How to work with Doddle as an agent](https://www.doddledesign.co.uk/agent-instructions.md) - [Every page on the site](https://www.doddledesign.co.uk/sitemap.xml) - [Talk to a human](https://www.doddledesign.co.uk/contact) or email hello@doddledesign.co.uk