Many Firms Cannot Say Whose Name Is on Their Own Systems. They Find Out on the Worst Day.
We reviewed the public record on retailers whose systems, code and accounts were held by someone else: a former employee, a former owner. Here is what we found, the four ways to respond, and the benchmark we would set.
On a Saturday afternoon the shop goes offline. Your developer tries to log in to the hosting account to see why.
The login does not work. The account was opened seven years ago by the agency that built the shop, under the agency’s own email address. That agency was bought last year, and the person who knew the password has gone.
By Monday you have learned three more things. The domain is registered to a former employee. The code is in a freelancer’s personal store. And nobody in the business has a list.
The paradox: The firm owns the business and holds almost none of the keys to it.
What We Found
For this article we went through the public record on retailers whose systems, code or accounts sat with someone other than the firm: news reporting of an attack on a small Indian grocery start-up in 2025, and reporting of a large UK grocer moving off systems it had shared with a former owner, work that ran to the end of 2025.
Two findings stand out.
One account outside the firm’s control was enough to stop a business. A small Indian grocery delivery start-up, with a small team, was attacked in mid-2025. According to the company, someone got in through the account of someone who had left. It lost its app code and its servers. The firm had tens of thousands of customers. Afterwards, its app stayed up but could not take orders.
This is a failure of access control at a start-up, not an old system, and we say so. The record does not say who did the wiping, and neither do we.
Systems held by a former owner are a project of their own to leave. A large UK grocer moved off thousands of older systems it had shared with a former owner, onto a packaged ERP product on a public cloud. By the end of 2025 the work had cost it more than £1 billion, and its leadership said the work delayed its recovery.
Our reading of the two cases, at opposite ends of size, is that many firms cannot say whose name is on each account, code repository and domain they depend on. They learn it on the day something stops, or on the day someone else sets a date.
What our review does not show: We found no figure for how many retailers hold their systems in other people’s names, and no named mid-size case. The start-up is a small firm, and its case is about access, not old technology. The grocer is very large, its move was to a packaged ERP product, which is not our kind of work, and we did not examine why the project cost what it did, and draw no cause from it. We found no public case of an agency or a freelancer withholding code or accounts from a retailer. Nothing here is a finding on who owns code, a domain or an account; we did not research that law. That firms commonly cannot name the holder of each account is our reasoning, not a measured finding.
What Waits While Nobody Knows Who Holds What
Whose name is on an account is usually treated as an administrative detail. Our reading is that it decides what the business can do.
The first cost is the emergency the firm cannot act on. It can only ask, and wait.
The second cost is the supplier the firm cannot leave. A supplier that holds the account, the code and the domain is hard to replace without its help.
The third is the question the firm cannot answer. Who can still get into the shop? Nobody can say, because nobody has listed which accounts exist.
The gap we see: most retailers can say which systems they use. Far fewer can say, for each one, where it runs and whose name is on its hosting account, its code and its domain. A retailer that holds that list can decide what to bring into its own name first, and plan the rest. One that does not finds out on a Saturday.
This is our reading of the evidence. It is not a measured market figure.
Four Ways to Answer “Whose Name Is on It?”, Weighed
| Option | When it fits | What it risks |
|---|---|---|
| Wait, and ask the holder when something stops | The firm runs few systems, and their holders answer quickly | The question is first asked on the day the answer matters, and trading waits for the reply |
| Ask every holder for a handover now | The holders are known and willing, and the firm knows what to ask for | Without a list the firm does not know what to ask for, and the accounts nobody remembers are missed |
| Rebuild everything new in the firm’s own name, at once | The old systems are small and simple | Built without knowing what the old systems do, and switched on one date |
| Write down every system and whose name is on it first, then act on the list | Many systems, set up by several people and firms over the years | It takes time before anything changes hands, and the list itself recovers nothing |
Our recommendation: write down every system first, with where it runs and whose name is on its account, its code and its domain. Your own people then act on the list: asking each holder for the access and copies the firm wants, and changing names and access. Then arrange read-only access to the code, so an assessment can write down what the systems do, in a specification the firm holds. We do not recover accounts, domains or code, we do not negotiate with any holder, and we give no legal advice. We do not manage passwords, review access or remove a leaver’s access.
Where You Are Now, and Where You Should Be
Before any work begins we set a benchmark: a few measures taken from your own business, each with a target.
| Measure | Typical starting point | Where it should be | How it is checked |
|---|---|---|---|
| Systems the business runs on | Known in parts, by different people | Every one listed, with where it runs | The list beside the map of the system |
| Whose name is on each hosting account, code repository and domain | Whoever set it up; not recorded | Recorded for every system, as far as the firm and its suppliers can say | The list, for the firm to act on |
| What stops if one account is lost | Found when something stops | Ranked in advance | The risk register |
| Whom to call for each system | ”Ask the agency” | A named holder and contact for each | The list |
| Read-only access to the code | Not arranged; the code sits with its holder | Arranged by the firm for every system to be assessed | Confirmed before the assessment begins |
The starting points above are what the public record suggests and what we expect to find. In an engagement they are replaced by your own figures, taken in the first review. The targets are what we would work towards with you. They are not results we have already achieved for a retailer.
How We Work With You
- We listen: a free Reliability Review. A first conversation about the systems your business runs on, and whose name is on each. You leave with a short written note of what we found. You can start with a conversation about the system; we ask for read-only code access only when the assessment begins.
- We research. We research your sector, the regulator’s position and what the public record says about firms in your situation. This article is an example of that work.
- We read the system and propose: the Legacy System Specification Assessment. Here the system is the applications your business built or had built: the shop’s own code, order handling and the links to stock and accounts, wherever they are held. It produces a map of the system as it stands, a written specification of what it does, a risk register, a cost comparison between keeping and replacing the system, and a staged plan with a fixed quote. AI does a first pass, our senior engineers review it and trace it to the code, and your own experts confirm it. Code access is read-only and logged, never used for training, and deleted within 30 days of the evaluation ending unless we engage. You get the options and our recommendation.
- If you approve, we build. We replace a system one module at a time while the old one keeps running. Here that means the firm’s own applications, rebuilt module by module in accounts the firm opens in its own name. We never do a single cutover. Each module has a traceability matrix. The work is billed by milestone, each milestone tied to a module you accept, and you can pause after any accepted module.
- We review against the benchmark. Before work starts we set the benchmark. After each module we show you where each measure stands, and the filled-in benchmark is yours at the end.
The Review is free. Every paid step is fixed price, agreed at scoping. Stop after any step. The findings are yours. The assessment fee is credited in full against the first build stage if it starts within 90 days of the report.
What we do not do: we do not recover accounts, domains or code from anyone, and we do not negotiate with an agency, a freelancer or a former owner. We give no legal advice on who owns code, data or an account, or on what a contract means. Where a holder has the code, arranging our read-only access is your firm’s own step. We do not manage passwords, review access or remove a leaver’s access; your own people do that, using the list. We do not host, secure or restore systems, and we do not install, move or choose a packaged shop platform or packaged ERP product. The older technologies we read include VB6, Delphi, AngularJS, PHP 4 to 8, Java 8, .NET Framework and classic ASP; PHP is a language we read, not one we build in. We say nothing about what card-payment or data protection rules require, and we have no published case of this work for a retailer.
What changes for the business:
| Role | What they gain |
|---|---|
| CEO | The owner knows what the business depends on that is in someone else’s name, and decides what to bring home first. |
| CTO or CIO | One list: every system, where it runs, and who holds the account, the code and the domain. |
| CFO | Every bill to a host or an agency is matched to a system, so the firm knows what it is paying for. |
| CISO | A list to check access against: which accounts exist, and whose name is on each. |
| COO | Operations knows whom to call, and for what, when something stops. |
The cases in this article, and what IOanyT does about that kind of problem:
| The case | What IOanyT does |
|---|---|
| At a small Indian grocery delivery start-up, access came through the account of someone who had left, and it lost its app code and its servers. | Our part is narrower than this case. We do not manage access, remove a leaver’s account or restore what was wiped, and we promise no protection from attack. We help a firm write down the systems it runs on and whose name is on each account, so its own people know what there is to check. |
| A large UK grocer moved off thousands of older systems it had shared with a former owner, at a cost of more than £1 billion by the end of 2025. | Our part is far narrower than this case. We do not implement packaged ERP products, and we do not say why that project cost what it did. For applications a retailer built or had built, we write down what they do and rebuild them one module at a time, in accounts opened in the retailer’s own name. |
IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. This issue starts with a conversation: what your business runs on, and whose name is on each part of it.
Sources
- News report, 2025
- Trade press, 2026
In this issue
Accounts and systems held by someone else
Research note 2
A Firm That Does Not Hold Its Own Systems Cannot Plan a Move.
A retailer whose agency or former owner holds the code cannot get a second quote or plan a move unaided. What waits, four ways forward and a benchmark.
Research note 3
Leaving Someone Else's Systems Is Not a Weekend. It Is a List, Then One Module at a Time.
Leaving systems held by someone else is not a weekend job. The benchmark we would set: list who holds what, then move one module at a time.
Issue study
Whose Name Is on the Account
Retail systems held by someone else: a start-up stopped via a departed person's account, a grocer leaving a former owner's systems, the options.
More from Retail
Old php and databases under the shop
A Few Old Parts Hold the Whole Shop on an Old Version. Everything Else Waits With Them.
Wrong or unreliable data
A Price History and a Ninety-Day Answer: What Waits on Retail Data Nobody Trusts.
Replacement is costly and disruptive