A global software vendor handed us the maintenance and modernization of their flagship platform — a system serving roughly 80 enterprise accounts across 20 countries. It keeps shipping while we rebuild underneath it.
Most modernization work starts with a codebase nobody on the team wrote. Ours did. The platform is a mature .NET and SQL Server application with years of reporting built on top of it, in daily use by enterprise customers on several continents. There was no pause, no freeze, no parallel rewrite. The product had to carry on serving its customers throughout.
Our remit covers two jobs at once: keep the current release healthy — incident response, defect triage, customer-reported issues, release support — and move the platform off the parts of its stack that have run out of road. The two compete for the same hours, so we treat them as one plan rather than two teams.
One reporting query on the platform swung unpredictably between a third of a second and half an hour, depending on which execution plan the database happened to cache. On a single day it ran 57 times at an average of 19 minutes. Users experienced it as “the system is down”; the hardware was almost idle throughout.
We reproduced it away from production on an isolated instance built to match the live engine, collation and settings, then measured every candidate fix on the same workload:
Time scale is logarithmic — each gridline is ten times the last. The same query, the same data, the same server.
The last figure is the point of the method. The obvious fix — raising the database compatibility level — looked convincing on a fresh run and failed under the exact conditions that caused the incident. Measuring it in the lab is what stopped it reaching production as a fix that would not have fixed anything. The same investigation surfaced a nightly maintenance job rebuilding every table across roughly 160 databases, and a latent bug producing duplicate rows in a report, neither of which anyone had asked us to look for.
Maintaining someone else’s product means the release process has to be boring and identical every time, whoever is on shift. Ours is a single path from branch to production, with gates that can fail the release rather than merely report on it.
The same path for every change, ours included. The only human decision is which tagged release gets promoted.
Our engineers work alongside AI coding agents every day — reviewing pull requests, reading unfamiliar parts of a large codebase, drafting migrations, reproducing defects, and pulling evidence out of production logs and query plans. On an inherited platform with years of accumulated code, that is the difference between an investigation taking an afternoon and taking a fortnight.
What matters more is where the boundaries sit, and they are written down rather than assumed:
An automated review produces a list a human then judges. No agent merges its own work, and no agent’s conclusion reaches production without an engineer who agreed with it.
Agents run on the client’s own infrastructure under the same isolation contract as our engineers. Real data is not posted to outside services to get an answer.
The tooling runs on subscription licensing, so heavier review of a risky change costs the client nothing extra and nobody is tempted to skip it.
Anything an agent asserts about a system is verified against the system before it becomes a recommendation. A finding that cannot be reproduced is not a finding.
Maintenance, escalations and platform work sit with us. The vendor’s own team keeps building the product their customers are paying for.
Defects, escalations and platform work all arrive through the same tracked pipeline, so the vendor can see what is queued, what is moving and what is done without asking us.
Every recommendation arrives with the measurement behind it — the plan, the timing, the before and after — so the vendor can overrule us on their own terms.
Architecture, database and delivery experience on tap for the weeks it is needed, not a permanent seat on the payroll.
This engagement is the shape most of our professional services work takes: an established product, a small internal team, and a backlog of platform debt that never reaches the top of the list. We are useful when the system matters too much to experiment on and there is nobody spare to do the careful version.
Framework and database upgrades, dependency untangling, and the measurements that say whether the upgrade was worth it.
Defect triage, customer escalations and release support for a product you no longer want to staff full time.
Root-cause analysis on live systems — query plans, indexing, jobs — reproduced in a lab before anything changes.
Architecture and delivery oversight for teams that have the developers but not the senior seat.
No sales engineer in the middle. You speak to the engineers who would run the engagement.
Start a Conversation