Modernise the legacy software your business still runs on

Fixed-price after a 15-minute scoping call and a short discovery session. A focused single-module replacement (one painful workflow, one or two integrations) takes 6–10 weeks. A full multi-module modernisation with data migration, mobile, integrations and reporting takes 12–24 weeks. Enterprise platforms running on VFP / VB6 / Delphi with hundreds of forms can run 6–12 months. You know the price before any code is written.

Depends on size, complexity and how willing you are to change the UI. Small modernisation (one workflow, single team, < 30 forms): 6–10 weeks. Mid (multiple modules, 30–150 forms, several integrations): 10–20 weeks. Large enterprise legacy (200+ forms, 50+ users, deep DB logic): 5–12 months — usually delivered module-by-module so value lands inside fortnight one, not at month six.

Yes — and we've done them. Pattern: DBF data extracted to staging, schema normalised into SQL Server or PostgreSQL, FoxPro forms re-spec'd as a modern web UI, FoxPro report-writer reports preserved as PDF templates with the same parameters, FoxPro code logic (stored locally in the .fxp / .prg) translated to server-side procedures. The classic 5-line FOR EACH → SELECT-SQL → REPORT FORM pattern usually compresses dramatically in the new stack.

All routine. VB6 (EOL since 2008) usually becomes React + Node.js or .NET 8 + Blazor. Classic ASP becomes ASP.NET Core or Node. Delphi 7 / XE forms become modern web UIs with the same Pascal-y server logic re-expressed in TypeScript or C#. PowerBuilder data-windows are the trickiest — but they translate to React + server-side query patterns. The deeper the EOL runtime, the more value modernisation creates.

Reading the existing code carefully is half the job. We document every business rule (often surprising the current team) before re-writing. Stored procedures stay close to the database when that's right; UI logic moves into modern services where that's right. We don't silently change behaviour — every deliberate change goes on a list you approve.

Depends on what's broken. Lift-and-shift (re-host the legacy app in modern infra) helps when the code is okay but the runtime is EOL. Refactor (re-stack the front-end, keep the database and core logic) helps when the UI is the problem. Full rewrite is right when the code base is the problem — usually when nobody understands it any more, or when the language is so dead nobody can be hired. The scoping call tells us which.

Yes — source code, schema, deployment scripts all yours in your GitHub or Azure DevOps from day one. The legacy code stays available as a long-term reference / rollback artefact — you don't lose it just because you no longer run it in production. Hosting on the new system is yours.

Parallel-run is the default — legacy and new run side-by-side for the test period, with new system loaded from a daily delta of production data. Tested rollback runbook ready before cutover begins. Legacy system stays read-only after cutover as a safety net for the first week. Module-by-module cutover where the architecture allows it — never a "big bang" if there's a safer way.