The system works. Orders come in, data reaches the ERP, the sales team can use the CRM and incidents get resolved. Tests passed, the project was delivered and there is no obvious reason to consider it a problem.
Then something needs to change.
The person who built an integration is on holiday. A former supplier registered the infrastructure account with their own email address. Nobody knows why certain records are excluded from synchronisation. Backups exist, but there is no record of a restoration test. The code is in a repository, yet releasing a new version requires a sequence of steps that was never written down.
None of this necessarily means the software was poorly built. It means the company depends on information, access or decisions it cannot manage with confidence. That risk becomes visible during an incident, a product change or a supplier transition.
When assessing the quality of a technology project, asking whether it works is only a starting point. The company also needs to know who can operate it, maintain it, change it and take responsibility for it tomorrow.
Code is only one part of the system that supports operations
An application rarely runs alone. Even a relatively simple development may rely on a database, an email service, a payment provider, several APIs, cloud infrastructure, a domain, analytics and internal processes that never appear on screen.
All those components still need managing after delivery. Services must be renewed, permissions reviewed, errors detected, changes released and incidents handled. Someone also needs to understand how a change in one component might affect another process.
Consider a platform that receives customer requests and sends them to an internal system. Its main feature may be perfectly implemented. Yet if nobody knows what happens when the internal system rejects a request, who receives an alert or how to resubmit it without creating a duplicate, the business will have to handle the exception manually. The operational problem exists even when the interface and code do precisely what they were built to do.
Continuity depends on preserving the system’s context: what it does, what it relies on, who is responsible for each part and how to respond when expected conditions no longer hold.
Risk one: access exists, but the business does not control it
Accounts are often created quickly during a project. Someone registers hosting, connects an API, configures transactional email or buys a tool for testing. Unless ownership is agreed from the outset, essential services can end up tied to one person’s email address or payment card.
While that person is working on the project, the issue may go unnoticed. It surfaces when a service needs renewing, permissions must change, billing needs to be checked, a security alert arrives or a new supplier joins the project.
Control does not mean sharing one administrator password with everyone. That approach creates problems of its own. It means the company has an administrator account under its control, can grant each participant appropriate permissions and can revoke them when their work ends.
For a system that supports operations, the business should know who controls at least:
- Domains, DNS and certificates.
- Infrastructure, environments and billing accounts.
- Code repositories and deployment processes.
- Databases, backups and monitoring tools.
- Accounts and credentials for external services, including payment, email and APIs.
If an asset is essential, the company needs to know where it is, who can administer it and how its management could be transferred. It should also distinguish what it owns from what it uses under licence and understand the contractual conditions attached to each component.
Risk two: decisions are understood only while someone remembers them
Many projects accumulate decisions that are not obvious from reading the code. An integration may wait before retrying an operation to avoid duplicates. A form may hide a field because the source data is unreliable. A process may run overnight because it would interfere with another task during business hours.
The person who made those decisions usually remembers the reason. Someone joining six months later sees an unusual rule and may decide it is unnecessary. Removing it can bring back the problem it was designed to solve.
Recording decisions does not require a transcript of every meeting. What matters is preserving those that affect maintenance and future changes: the issue observed, the chosen approach, relevant alternatives, dependencies and the circumstances in which the decision should be reviewed.
This is particularly important where software implements business rules. A technical comment may explain how a figure is calculated, but it may not explain why one customer group is treated differently, who approved that exception or what would happen if it were removed.
Useful documentation helps a new person understand what can be changed safely and what must be checked before making a change.
Risk three: incident response depends on one person
Some people will naturally know a system better than others. That becomes a business risk when an incident cannot be diagnosed or contained without finding one particular individual.
Imagine an integration stops sending orders. If only one person knows where to find the errors, how to distinguish a temporary failure from invalid data and which orders can be processed again, the company’s response depends on their availability. Adding more developers does not resolve that dependency by itself. They need access, context and a procedure they can follow.
A sensible initial response should answer concrete questions: which business process is affected, when the issue started, how many transactions might be pending, where the error was recorded, who should be alerted and which actions are safe before the underlying cause is fully understood.
Short instructions for predictable incidents, together with named responsibilities and escalation criteria, can capture that knowledge. They cannot guarantee an immediate solution to every problem. They can prevent the first hours from being spent working out where to look or whom to call.
Risk four: backups and deployments exist, but recovery has not been tested
“We have backups” and “we can recover the service” are different claims. A backup may exist but be incomplete. It may contain the database while excluding necessary files. It may be stored correctly yet require a restoration process nobody has tested.
The same applies to deployments. An easy release process does not guarantee an easy rollback. If an update changes data or modifies a database schema, restoring the previous application version may not be enough to make the system work again.
Continuity requires knowing what is needed to recover a specific business process and checking that the procedure works. Depending on the system’s importance, this may involve restoration tests, a way to reverse changes, instructions for rebuilding an environment and prior agreement on who can authorise an intervention.
The level of preparation should match the impact of an outage. An internal tool used occasionally and a platform that handles orders or customer services do not need identical procedures. Both require their owners to understand what would happen if the system became unavailable.
Continuity needs to be part of delivery from the start
Trying to resolve all these issues at handover is often too late. Accounts may already have been created under the wrong ownership, key decisions may never have been recorded or an integration may have operated for months without enough information to investigate its failures.
The work begins when the project is defined. The company and its supplier should agree which assets will be used, who will own them, which processes are critical, what each party is responsible for and what support will be required after launch. Those decisions shape access, environments and procedures around the reality of the business.
During development, continuity is maintained through specific habits: recording decisions when they are made, managing access by role, making changes traceable, keeping track of dependencies and ensuring failures leave useful evidence. Before production, the team should check deployment, monitoring, backups and the actions available during an incident.
Handover then needs to transfer real capability. A set of documents may be part of it, but a more revealing exercise is to ask another authorised person to locate an error, release a controlled change or explain how they would recover a service. If the information and permissions provided do not let them do that, delivery is not yet complete.
How to check without turning it into an endless audit
An initial review can focus on five questions:
- Ownership: Do we know who owns the essential assets and who can administer them?
- Operations: Do we know how the system is monitored and who responds to a problem?
- Change: Can another authorised person understand, test and release a modification?
- Recovery: Do we know which data and services must be restored, and have we tested the procedure?
- Knowledge: Are the decisions and exceptions a new person needs to understand recorded somewhere accessible?
Not every negative answer has the same urgency. Priorities should reflect business impact: which process would stop, how many people would depend on it, how long the problem might go undetected and which alternatives would be available while it is resolved.
The review should produce decisions and actions with clear owners. That might mean moving an account under the client’s control, documenting how orders are processed again, configuring a useful alert or testing a backup restoration. Continuity improves when each identified risk has a concrete way to reduce it.
A sound handover lets the business choose what happens next
A company may work with the supplier that built its technology for many years. That relationship is stronger when the client knows what it owns, has enough information to make decisions and understands each party’s responsibilities. It can then request improvements, bring in specialists, change priorities or prepare a handover without first negotiating access or trying to recover lost knowledge.
At Pibeca, we address ownership, documentation and the ability to evolve as part of building digital platforms and products. When a system already exists, we first need to understand its dependencies before promising changes or timelines.
If you are planning a project or need to regain control of a system your company relies on, tell us what you need to build or review.
And ask one final question: if someone else had to take over the system tomorrow, could they do it without reconstructing its history?
Frequently asked questions about technology project continuity
Can a well-built technology project still put a business at risk?
Yes. The code may behave as intended while the company still depends on accounts it does not control, an unknown deployment process, undocumented decisions or one person who can resolve incidents. Development quality should also be assessed through the system’s ability to be operated, maintained and handed over.
Is delivering the source code and documentation enough?
Not always. Code and documentation matter, but another person also needs appropriate access, knowledge of the infrastructure and integrations, procedures for releasing changes and a way to diagnose errors. A useful test is whether an authorised person can actually perform those tasks with what has been handed over.
Should infrastructure and accounts always be registered in the client’s name?
The business should have effective control over essential assets. The precise arrangement depends on contracts and the services involved, but the client should be able to identify who owns them, manage permissions, keep the service running and organise a handover. It is best to clarify this before creating accounts.
How often should backups be tested?
There is no single schedule that suits every system. It depends on how much data the business could afford to lose, how long the process could be unavailable and how frequently the application and infrastructure change. What matters is setting a suitable schedule, assigning responsibility and checking that restoration results in a usable system.
How can a company reduce its dependence on one person without losing their knowledge?
Turn the information they use to do their work into knowledge available to other authorised people: significant decisions, deployment steps, error locations, recovery procedures and escalation contacts. Then validate it through real or simulated tasks performed by someone who did not build the system.
Does continuity require a permanent support contract?
Not necessarily. It requires deciding what response each process needs and preparing the means to provide it. Some systems need monitoring and agreed response times; others can operate with scheduled reviews and support during defined hours. The choice should reflect the impact of an interruption and be clear to both the business and its supplier.
