This isn't theory
Eighteen years modernizing one system — without ever stopping it.
Over eighteen years, the same core team modernized Formpak's entire platform while the business kept running every single day. Windows to Linux. Containerized with Docker. The database migrated from DB2 to MSSQL and PostgreSQL. Java upgraded from 1.5 through to 17, across many generations of the stack. AI introduced into the development workflow to make the work faster and the system easier to maintain.
None of it happened as a single disruptive rewrite. Each evolution was phased, tested, and rolled out carefully — so the platform stayed continuous while it changed underneath. Formpak grew from a handful of clients to more than a hundred. The team didn't just maintain the software; they came to understand the business.
If you've already decided to move
Legacy system migration, in steps that don't stop the business.
Sometimes modernizing in place isn't the answer. The platform is end-of-life, the vendor is gone, the hosting bill no longer makes sense, or the business has outgrown the architecture. Then the system has to move: to a new stack, a new database, a new cloud, or from one monolith to services you can change independently.
We do that the same way we modernize — one step at a time, with the old system running until the new one has proved itself. Learn the system first. Migrate the data with reconciliation you can check. Run old and new side by side. Cut over one capability at a time, with a way back at every step. Every migration in the Formpak story above — operating system, database, runtime, containers — was done this way, and none of them cost the business a day.
Then comes the part most migration projects skip: the new system is now your most important one, and someone has to keep running it. The engineers who moved it already know every decision inside it. Where you want it, they stay on as your dedicated team, hold the production environment, and answer for it. The more the system matters, the more that continuity is worth.
AI, in two directions
A system AI can work on. Then a system that uses AI.
The first thing modernization buys is a codebase AI tools can actually read, test and change safely — structured knowledge, tests around the behaviour that matters, dependencies brought current. That alone changes what every future change costs.
The second is adding AI to what the system does: document handling, search, classification, the repetitive judgment calls your staff make inside it every day. We build those in behind the system's existing rules and permissions, so the business logic you've trusted for years still decides what the AI is allowed to touch. Start with one workflow, measure it, then widen — the same way we approach everything else on this page.
Happening right now
A ten-year-old product. A team that had said no to AI.
A SaaS company with a product nearly ten years old and a fifteen-person engineering team had, until recently, resisted AI entirely. They added a single Core70 engineer — not to rewrite anything, but to use AI to raise code quality and security on an established codebase. Within weeks, the team itself had started adopting AI in their own work.
This is what modernization usually looks like in practice: not a big-bang cutover, but one engineer showing a cautious team that the system can get safer and easier to work with — without putting the business at risk.
How it actually works
Knowledge first. Then code.
A legacy system is dangerous to change because the knowledge of how it works has leaked away. So that's where we start. A senior engineer learns your system from the inside and builds a structured knowledge base — the business rules, the dependencies, the reasons things are the way they are. With that context in place, AI becomes genuinely useful: it can help reason about impact, generate routine changes, and surface what a rewrite-from-scratch would have missed. The engineer stays focused where judgment matters — architecture, business logic, the decisions a model shouldn't make alone.
We're applying the same approach to our own twenty-year-old internal system right now — so we know exactly what we're asking you to take on.
This is part of how we build everything. See our full approach →
Systems like this usually need someone to run them, not just change them. That's a dedicated team — we hold the production environment and answer for it. What that means →
Free code health check
A senior engineer reads your codebase and sends a written report within a week of getting access — what's solid, what's risky, and what it would take to move it forward. We read the code before we quote on anything, so this is a step we'd take anyway. The findings are yours whether or not you work with us.
Get your free code health check