Two services, one method

Legacy modernization

Migrating the systems that still run the business — without a rip-and-replace rewrite that puts eighteen months of risk on the table.

A working system that has been posting transactions for twenty years is not technical debt. It is a specification, written in the only language that never lies: production. The problem is rarely the software. It is that the platform underneath it has stopped being supported, the hardware is a single point of failure, and the people who understood it have moved on.

We move these forward while they keep running. The data comes with it. Users keep the workflow they already know. Nothing is rewritten for the sake of being new.

What we work on

• 16-bit DOS applicationsCharacter-mode systems still doing daily work.
• Clipper and HarbourIncluding recompiling Clipper sources under Harbour for a supported, modern target.
• FoxPro and AccessDesktop databases that outgrew the desktop.
• VB6Applications whose runtime is long past support.
• Classic ASP and old IISWeb front ends built before the frameworks existed.
• Windows Server upgradesThe migrations deferred one year at a time until the hardware became the risk.

How a migration actually goes

1. Inventory what runs. Not what the documentation claims — what is actually in production, on which box, talking to what. Most surprises live in that gap.
2. Prove the hard part first. Every legacy system has one thing that decides whether the move is possible at all: a driver, a data provider, a licence. We test that before anything else is planned or priced.
3. Stage the whole thing. The new environment is built and exercised in full while the old one carries the business.
4. Cut over deliberately. One system at a time, lowest-stakes first, with the old environment left standing until the new one has earned the traffic.

Applications

Mobile and custom line-of-business software — built, published and maintained.

iOS and Android on Capacitor and Supabase, and custom software for the work that no package quite fits. Usually this grows out of the first service: once a system is on a supported platform, the things it could never do become straightforward.

Published means published. The build, the code signing, App Store Connect and Google Play, responding to review, and the post-launch updates that keep an app from quietly dying at the next OS release. That last part is where most app projects actually fail.

Capability

• iOS and AndroidCapacitor, one codebase, native where it needs to be.
• SupabaseData, auth and realtime without operating a back end.
• Store pipelineSigning, App Store Connect, Google Play, review responses.
• Line-of-businessOrder entry, inventory, plant-floor collection, routing.
• IntegrationWeb services tying warehouse, scanner and office together.
• Post-launchThe updates after release, which is the part that matters.