GBCORP BLOG · IT SERVICES
Software Technology Partner: Taking Over Inherited Software
Many companies start looking for a software technology partner when software is already running and the people who wrote it have gone. The first job is not new features. It is finding out what you have, and getting the keys back.
A software technology partner takes ongoing responsibility for software a business depends on: keeping it running, changing it safely and advising on what to do next. GBCORP takes on new builds and inherited systems alike. Inherited software calls for a particular order of work, because a previous vendor, a departed developer or a half-finished project usually leaves questions nobody can answer yet. Promising new features before answering them is how a second expensive mistake begins.
The order of work on inherited software
| Step | What is checked | What you get |
|---|---|---|
| Access | Code, cloud, domain, store accounts, payment gateway, e-mail | A list of who holds what, and what is missing |
| Rebuild test | Build from source and restore a backup to a test environment | Proof the business can recover, or a clear gap |
| Risk review | Security, outdated parts, recurring failures, undocumented rules | A ranked list of what could hurt, and when |
| Decision | Stabilise, extend or replace, part by part | A written plan with fixed quotations |
Getting the keys back
The most common surprise is that important accounts are in the wrong name: a domain registered personally by a past employee, a developer account belonging to an agency, a cloud project on someone else’s card. Recover them first, before any engineering. Domain registrars have transfer processes, and both Apple and Google Play have formal routes for moving an app to another developer account, which need the current holder’s cooperation. If a relationship has ended badly, a calm written request with a deadline works better than a dispute. Take legal advice if it does not.
Stabilise, extend or replace
Stabilise first if the software does the job but frightens everyone: add monitoring, tested backups, tests around the riskiest parts and documentation. Extend if the foundation is sound and the business needs more. Replace only where the review shows that fixing would cost more than rebuilding, and then usually part by part. Customers and data must keep moving while the work goes on. A rewrite that stops the business is rarely the honest recommendation, even when it would be the most profitable one for a supplier.
Checklist before engaging a partner
- List every account the software depends on, and who holds it.
- Find the latest contract and what it says about code ownership.
- Locate the source code, and confirm it matches what is running.
- Take a fresh export or backup of the data you can reach today.
- Write down what breaks most often, and who knows how to fix it.
- Ask each candidate how they would spend their first week.
The numbers to expect
The review is scoped like any other work: one week, priced on its own, ending in written findings and a fixed quotation. Stabilising or extending then runs in releases of two to six weeks at a fixed price, and support continues at a known monthly figure. Customised or more complex functionality is quoted separately before any work starts.
A worked example
Consider a logistics firm whose booking system was written by a contractor who has since moved on. It works, mostly, and nobody dares touch it. The review week finds the code in the contractor’s personal repository, the domain in the firm’s name, the server on a card that expires soon and no tested backup. A friendly e-mail recovers the repository. The restore test fails first time, because a configuration file exists only on the live server, and fixing that is the most valuable work of the month. Monitoring and a set of tests around booking and invoicing come next. The review concludes that the core is sound but one reporting module should be replaced. Six months later the firm is adding features to software it no longer fears, at a fixed price per release.
Signs of health and signs of trouble
A review looks for plain signals. Healthy software has its code in one place, a repeatable build, automated tests around money and data, a written list of scheduled jobs and outside services, and logs someone reads. Trouble looks like changes made directly on the live server, rules known to one person, passwords inside the code, years without updates and no record of why things were done. None of this is unusual, and none of it is a reason to panic. It is a reason to rank the risks and deal with the worst first.
Handing over without a fight
Most outgoing suppliers cooperate when the request is specific and the deadline reasonable. Ask for the repository, the account transfers, a list of scheduled jobs and outside services, and an hour of a developer’s time to answer questions. Pay for that hour if necessary, as it is among the cheapest engineering you will ever buy. Keep the tone practical, since you may need a second call when the first surprise turns up.
Security in the first week
When a supplier or staff member leaves, access often stays behind. Change passwords and keys, remove former users from every system and turn on two-step sign-in wherever it is offered. This takes little time and closes the largest risk early, before anyone has read a line of code. It should be done even if the relationship ended well.
Data comes first
Whatever else happens, the data must be safe and usable. Confirm a backup exists, restore it somewhere harmless and check that the result opens and makes sense. An untested backup is a hope rather than a plan. If personal data is involved, note where it is stored and who can reach it, because that answer may need to change too.
Documentation as the first deliverable
A partner’s first useful document is a plain description of how the software works today: components, accounts, scheduled jobs, outside services and the rules nobody wrote down. It helps the current team, and it protects the business from ending up in this position again. Ask for it in writing, and ask for it to be kept current with each release.
How the work is priced
Scoping is priced on its own, then there is a fixed price per release, then support at a known monthly figure. Avoid open-ended hourly arrangements on inherited systems, because uncertainty is highest at the start and an hourly meter places all of it on you. If something turns out harder than expected, it should appear in the next quotation, and you can decide whether it is worth doing.
Ownership terms
The end state is simple: code in a repository the business controls, cloud project, domain, store accounts and payment gateway in its own name, documentation current and data exportable. No credentials are retained by the partner after a hand-over unless a support contract requires them. That way the next change of partner, if there is one, takes days rather than months.
Questions we hear first
What if we do not have the source code?
Then the review starts from the running app and the data. A rebuild may be the cleaner route, and the review says so in writing.
Will our previous vendor have to be involved?
Only where they hold something you need, such as an account or the code. A short, practical exchange is usually enough.
Does the review put the live system at risk?
No. The review itself changes nothing in production. If it finds something urgent, that is raised at once and fixed at an agreed price.
Are we tied to GBCORP afterwards?
No. Code, accounts and documentation stay in your name, so changing partner later is a hand-over rather than a rescue.
Where to start
The GBCORP software development hub sets out the method; the GBCORP Custom App Development product is the priced route where a rebuild is the answer. For what a partner should commit to, read technology development partner; for older apps, read app modernisation.
GBCORP operates across 17 countries on 4 continents through six pillars: AI & IT, Innovation, Sustainability, Infrastructure, Business Lounge, and EV's & Solutions.
