Home/Legacy Migration
Your old system isn't a problem. Losing it would be.
That FoxPro, Clipper or Access application has quietly encoded decades of how your business really operates — including the exceptions nobody ever wrote down. The goal is never to throw it away. It's to carry it forward.
The situation
It still works. That's exactly what makes it dangerous.
Legacy systems rarely fail dramatically. They just accumulate risk: the platform goes out of support, the last developer who understood it retires, the hardware it runs on can't be replaced, and the version of Windows it needs stops being allowed on the network.
Meanwhile it keeps doing its job perfectly well, which makes it very easy to postpone the decision for another year. And then another.
The mistake we see most often isn't leaving it too long — it's replacing it with an off-the-shelf product that handles eighty per cent of the business and quietly discards the twenty per cent that actually made you competitive.
Sound familiar?
- The application only runs on one ageing PC that nobody is allowed to touch
- Your IT policy or auditor has flagged an unsupported platform
- The original developer is retired, unreachable or no longer trading
- There's no source control, and possibly no source code
- Data lives in DBF files, an Access database, or a shared drive
- Nobody can add a field or a report without something else breaking
- Remote and mobile access are impossible, and now they're required
Why us specifically
We can read your old code, because we wrote code like it.
Most modernisation vendors approach a FoxPro system as an archaeological dig. We spent years building in these environments — Clipper, dBASE, FoxPro, Visual FoxPro, VB6 — and years since building in .NET and SQL Server. Both halves of the problem are familiar.
The rules survive
Twenty years of edge cases are sitting in that code. We extract them deliberately rather than discovering them from complaints after go-live.
The data survives
Including the historical records, the odd formats and the fields somebody repurposed in 2004 without telling anyone.
The workflow survives
If your team can enter an order in nine keystrokes today, the replacement should not take thirty and a mouse.
The next decade is covered
You end on a supported platform, in source control, documented, and buildable by any competent .NET developer.
How it runs
A staged migration, not a leap of faith.
Nobody sensible switches a trading business over in one weekend. Each stage produces something you can inspect and sign off before the next one starts.
Assessment
A short paid engagement: what the system does, how it's built, what the data looks like, and a realistic view of effort and risk. It ends in a written recommendation — sometimes that recommendation is to leave it alone.
Data model & migration scripts
A proper relational schema in SQL Server, and repeatable scripts that load your data into it. Repeatable matters: we will run them many times before the real one.
Rebuild by module
Delivered in working increments, in priority order, so you're using and correcting real software long before the end.
Parallel run
Both systems live, same inputs, outputs compared until the numbers agree and everyone stops being nervous.
Cut-over
A final data load and a switch, with the old system kept available read-only for as long as you want it.
Aftercare
The first weeks after go-live are when the remaining surprises appear. We stay close during them, then hand over documentation and source.
Where things end up
Common starting points, and where they land.
The destination is nearly always the same shape: a SQL Server database holding the data properly, a .NET application layer holding the business rules, and an interface appropriate to how your people actually work — desktop, browser, or both.
What varies enormously is the route. A tidy Visual FoxPro application with a clear data dictionary is a very different project from twelve years of accumulated Access databases with linked spreadsheets. The assessment exists to tell those apart before anybody commits.
Typical paths
Your combination isn't listed? It almost certainly still applies — ask.
Fair questions
The things people ask first
Can you migrate it if we don't have the source code?
Usually, yes — though it changes the approach. Where source is missing we work from the data structures, the compiled behaviour, the reports and screens, and from your staff, who between them know more of the rules than any document. It costs more than having the source, and we'll say so up front.
Do we have to replace everything at once?
No, and we'd usually recommend against it. A common pattern is to move the data to SQL Server first, leaving the existing application pointed at it, which removes the most urgent risk immediately and buys time for the rest.
How long does it take?
That depends entirely on how much business logic is in there, which is what the assessment is for. Anyone who quotes you a duration before they've looked at the code is guessing.
Wouldn't an off-the-shelf package be cheaper?
Sometimes, genuinely — and if that's the right answer for you we'll say so. The question worth asking is what your custom system does that no package does, and whether that difference is the reason customers choose you.
What happens to our historical data?
It comes with you. Migrating current records and abandoning fifteen years of history is a false economy; the history is where your reporting and your obligations live.
Will we be locked in to you afterwards?
No. You get the source code, the database schema, the documentation and the deployment process. Standard .NET and SQL Server, no proprietary layer of ours in the middle. Any competent developer can pick it up — we'd simply prefer you kept us because you want to.
Start with an assessment, not a commitment.
Tell us what you're running and what's prompting the question. A short look at the existing system is a small, contained first step — and it ends with a written answer either way.