Your business software, ready for what comes next.
Your software already supports part of the business. We review how it works and what it depends on, then plan improvements around the continuity of your team’s work.
A specific use.
A difficult takeover
Understand the code, access and how releases are delivered.
New requirements
Add a step, role or integration without fragmenting the workflow.
Technical debt
Address fragile components and manual maintenance tasks.
What we improve.
A takeover assessment
Dependencies, risks and checks needed before the first changes.
Your application building and running on our machines from your own repository, with the setup steps written down.
Changes in manageable batches
Defined fixes or features checked against essential workflows.
Tagged releases in your repository, each carrying its migration steps and its rollback command in the notes.
A transition plan
Data migration, deployment and rollback options to prepare.
A runbook in the repository, rehearsed once against a restored copy of production data.
How long it takes.
Three to five weeks before the first change reaches production, most of it spent getting the application to build outside your servers. You see it running on a staging copy at the end of week two, which is when we know the takeover will hold.
What we need from you.
An hour a week with whoever built it
Even if that person has left and now works elsewhere, an hour is worth paying for. Code records what happens and almost never why a rule was written that way, and guessing at those rules is how a takeover breaks payroll.
Production data we are allowed to copy
An anonymised dump, or written permission to work on a restored copy. Otherwise we test against invented records, and the cases that break in practice are exactly the ones nobody thinks to invent.