A Record the Firm Holds
A study, from the public record, of manufacturers whose knowledge of their own systems sits with an outside partner or one person: one older account from a very large Indian manufacturer, what the wider record shows, the options, what we would advise against, and the benchmark we would set.
1. At a Glance
Issue study · From the public record. No organisation is named here. Everything about it comes from the public record.
| Organisation type | A very large manufacturer whose applications and infrastructure were each handed to an outside partner, set beside sources from outside manufacturing on written records, scarce skills and tool-drafted documentation |
| Size band | The firm in the record: very large. Our reader: a mid-size manufacturer whose dispatch, planning or costing applications were built and are looked after by an outside partner, or by one long-serving member of staff |
| Region | The public account: India. The other sources: the US and UK, large enterprises in several countries, and small and mid-size Indian firms |
| The decision at stake | Whether, and how, a firm should hold its own written record of systems that someone else understands, and what it would take to get one |
| The public outcome | In a former CIO’s account, its applications and its infrastructure were each handed to an outside partner. The account gives no cost, and we draw none |
| Why it matters to a mid-size manufacturer | A firm that holds nothing in writing about its own systems cannot answer its own questions, compare quotes or plan for one person leaving |
2. The Business Problem, in the Buyer’s Words
“Our dispatch system was built by a local software firm twelve years ago, and they have looked after it well ever since. Our planning tool was written by one of our own people, who still runs it. Both work. But when a customer asks how a charge was worked out, I have to ring someone. When we need a change, there is one quote. And when the person who wrote the planning tool goes on leave, the plant waits. I do not want to change anybody. I want the firm to know what its own systems do.”
These words are imagined. They describe the decision as the research shows it, not a real conversation.
The firm is not in trouble. Its partner is good and its expert is loyal. What it lacks is a record of its own, and every question, quote and absence shows the gap.
3. What We Found
Method. We went through the public record on manufacturers whose knowledge of their own systems sits with an outside partner or one person: one account from a very large Indian manufacturer, a vendor’s survey on documents that do not match systems, a vendor’s survey on scarce skills, one survey of small and mid-size Indian firms, and one engineer’s remark on documentation drafted by tools.
One account from the sector. The firm is a very large Indian manufacturer. In a press article some years ago, a former CIO described how its work had been arranged.
| What | Public record |
|---|---|
| The arrangement | Its applications and its infrastructure were each handed to an outside partner |
| The period | Over a decade ago, described some years later |
| What it cost | Not given in that account; we draw no cost from it |
| Whether a partner withheld anything | Nothing in the record suggests it, and we do not suggest it |
This is an older account of a very large firm, and the only public account in the sector’s research on this issue. We use only its description of how the work was arranged. What the firm went on to build is another organisation’s work and is not part of this study.
Records that do not match the system. In one survey of more than 600 technology leaders and practitioners in the US and UK, run by a firm that sells software tools, more than nine in ten reported harm to the business from a mismatch between the architecture as built and the documented standards. The survey covers every sector. It is about documents that no longer match what was built, not about firms with no documents at all.
Skills that are hard to buy in again. In one survey of about 500 senior leaders at large enterprises that run mainframes, about seven in ten said they had struggled to find the right skills; the skills include cloud, security and AI as well as the mainframe. It is a vendor’s survey, not about manufacturing, and mainframes are not IOanyT’s kind of work. In one survey of more than 400 small and mid-size Indian firms across IT, manufacturing, education and retail, more than half cite a lack of technical skills to adopt modern solutions.
A caution about records drafted by tools. One engineer, writing on a developers’ forum about a legacy codebase, described documentation that teammates had produced with AI tools as simply wrong and wholly made up, and said that no document can be better than a bad one. This is one person’s account, used only as a reason for engineers to review whatever a tool drafts.
Our reading of why the firm ends up holding nothing. These four are our reasoning from the record above. None is a finding of any source.
- Knowledge was treated as part of the service. The partner, or the one developer, was there so that the firm would not have to know. Nobody asked for a record.
- Each change deepened the dependence. Work was done well and not written down, so the system grew and the firm’s knowledge of it did not.
- Nobody else can read the scope. With nothing in writing, a second supplier cannot quote and a second engineer cannot safely make a change.
- The one who could write it down has no time. The expert is busy keeping the system running, and a notice period is far too short to hand over years of decisions.
What this record does not show. The sector’s research holds one sentence on this issue, about one very large firm, from an older account, and it gives no cost. Everything else is from outside manufacturing, two of the surveys are vendors’, and one source is a single person’s remark. We found no case of a partner withholding code or knowledge from a manufacturer, and no case of a partner overcharging one. We found no figure for what dependence on a partner or one person costs, what partners charge, how long a handover takes, or how many plants are in this position. The study uses the record as a lesson about the shape of the issue; it does not claim that any partner behaves badly, or that any mid-size manufacturer has lost money for the reasons above.
4. The Options a Firm in This Position Had
| Option | When it fits | What it risks | Our view |
|---|---|---|---|
| Stay as you are: ask the partner or the one person each time | Questions are rare, the relationship works, and nothing is about to change | Each answer is used and lost; the firm cannot check what it is told, compare quotes or plan for an absence | Right only as a pause with an end date |
| Ask the partner or the person to document the system | They are willing, have time, and it can be agreed as part of the work | The writer is also the one keeping the system running, and the running comes first. A notice period is too short for a handover | Worth asking; rarely enough on its own |
| Bring in a second partner, or hire a second person, to learn the system | A second supplier or a second engineer is wanted anyway | The firm pays for the learning and still holds nothing in writing; the knowledge is now in two places, neither of them the firm’s | Right as a later step, once a record exists |
| Have a tool draft documentation from the code | A quick first look is enough, and every line will be checked | An unchecked draft can be confidently wrong, and staff trust it | We would advise against this as the record itself |
| The firm’s own specification, written from the code, checked by engineers and confirmed by the firm’s people | The firm wants a record it owns and can hand to anyone, subject to its own contract with its present supplier | Costs money and changes nothing in the system; needs read-only code access, which the firm arranges, and the expert’s time to confirm | Our recommendation |
What we would have advised against: for a firm in this position, relying on a handover written at resignation; paying a newcomer to learn the system before anything is written down; treating a tool’s unchecked draft as the firm’s record; and, above all, letting the question of who holds the code go unasked until the day the answer matters.
5. Our Recommendation, and the Decision It Asks of the Board
For the applications an outside partner or one member of staff built and looks after: arrange read-only access to the code, as the firm’s own step with whoever holds it. Then have the system written down from its code, by engineers who trace each statement to it, and confirmed by the firm’s own people, including the expert or the partner if they are willing. The firm holds the specification and can hand it to anyone it chooses, subject to its own contract with its present supplier. The partner or the expert goes on looking after the system as before; staying with them becomes a choice. A rebuild follows only if the firm decides on one.
The decision it asks of the board: approve a fixed-price assessment, separately from any change or replacement budget, and ask the firm’s own management to arrange code access with whoever holds it. Then decide, with a record in hand, whether to stay, ask others to quote, or replace a part, stopping after any step.
6. Benchmark: Where You Are Now, and Where You Should Be
These are targets, not results. In an engagement the starting points are replaced by the manufacturer’s own figures, taken in the first review.
| Measure | Typical starting point | Where it should be | How it is checked |
|---|---|---|---|
| What the system does | Known to the partner or one person | Every function written down in plain words, confirmed by the firm’s own people | The specification |
| Firms able to quote from the specification | Only the holder | More than one, each pricing from the same specification | The quotes set beside the specification |
| Questions answerable without the one holder | Few: most wait for a call back or a return from leave | Answered in the building, from the record | A sample of recent questions, looked up in the record |
| Where the code is held, and who holds access | Not known, or never asked | Named, with read-only access arranged by the firm | Confirmed before the assessment begins |
| What a tool drafted | Not separated from what was checked | Every statement traced to the code and confirmed | The specification and its review record |
| What leaving would involve | Not known | Set out beside the cost of staying | The cost comparison |
7. How IOanyT Would Work
- We listen: a free Reliability Review. A first conversation about your systems, who looks after them, and the questions nobody in the building can answer. 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 study is an example of that work.
- We read the system and propose: the Legacy System Specification Assessment. Here the system is the applications an outside partner or one of your own people built and looks after, with read-only access to the code arranged by you before the assessment begins. 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.
- If you approve, we build. We replace a system one module at a time while the old one keeps running. Here that means a rebuild only if you decide on one; your partner or your own expert keeps the old application running meanwhile. We never do a single cutover. A traceability matrix links every old function to its replacement. 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. As the work goes on 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.
8. What the Client Would Own
- The map and the specification: what the system does, in writing, confirmed by the firm’s own people, which the firm can show to its present partner, a second supplier, or both, subject to its own contract with its present supplier.
- The risk register: what the assessment found, including what could not be established, listed before any price is set.
- The cost comparison: the cost of keeping the system as it is beside the cost of replacing it, so a renewal is decided knowing what leaving would involve.
- The filled-in benchmark: each measure, where it started and where it stands.
- If the firm chooses a rebuild: the rebuilt modules’ code, and a traceability matrix for each.
9. What This Approach Does Not Cover
- IOanyT offers no assistant that staff can put questions to. The research behind this campaign suggested one; IOanyT has not published one. What it produces is a document.
- IOanyT is not a staffing firm. It supplies no replacement for a partner or a person, and does not train staff.
- IOanyT does not obtain code, documents or access from a partner or from a member of staff, and does not negotiate with a partner. Arranging read-only access is the firm’s own step, before the assessment begins.
- IOanyT gives no legal advice. Who owns code or data, and what a contract allows a firm to show to another supplier, are for the firm’s own legal adviser.
- Employment questions, including how the firm raises the matter with a long-serving expert, are the firm’s. The expert is never the problem.
- IOanyT does not maintain a system or keep its record current after hand-over, and does not keep an old system running. A record nobody updates loses its value.
- A specification shows what a system does, not whether each rule is right. Rules nobody owns are listed for the business to decide.
- IOanyT does not work inside packaged ERP products, on plant control systems, or in RPG or COBOL.
- This study does not say IOanyT would have changed anything at the firm described, or that IOanyT has done this work for a manufacturer. IOanyT has no published case of this work for a manufacturer.
About this study: IOanyT did not work on this case. It is drawn from published findings, cited below.
10. Sources
| Source | Used for |
|---|---|
| Trade press article, 2022 | The public account: applications and infrastructure with outside partners |
| A vendor’s survey report, 2025 | Records that do not match the system |
| News report of a vendor’s survey, 2025 | Skills at large mainframe enterprises |
| News report of a survey of Indian small firms, 2025 | Skills at small and mid-size Indian firms |
| Developers’ forum post, 2026 | One engineer’s remark on tool-drafted documentation |
IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We write down what your systems do, so the firm holds its own answer whoever looks after them.
Read the research notes on this issue
Knowledge held by outside partners or one person
Research note 1
Ask Who Knows How the Dispatch System Works, and the Answer Is a Phone Number.
Many manufacturers must ask an outside partner or one person what their own system does. What the public record shows, four options, and our benchmark.
Research note 2
Only One Firm Can Quote for Changes to Your System. A Record You Hold Changes That.
When only the partner who built a system can describe it, only that partner can quote for changes. Four ways out, our recommendation and a benchmark.
Research note 3
When the One Person Who Knows Is on Leave, the Firm Should Still Have an Answer.
When one person or one partner is the only one who knows a plant application, the firm waits. Four ways out, weighed, and the benchmark we would agree first.