Inside an Automation Estate That No One Wants to Touch

RPA technical debt management becomes difficult long before an automation stops running. In an ageing bot estate, the harder problem can be recovering enough knowledge about dependencies, ownership and actual production behaviour to make one ordinary change without creating another failure somewhere else.

The ERP release is three weeks away.

According to the change notice, the impact on automation should be limited. A transaction screen is being reorganised. One authentication method is being retired. A field used by finance operations will move to a different tab.

The automation team opens the bot responsible for that transaction.

Its main workflow is understandable. The trouble starts around it.

A shared library was last changed by an engineer who left the company. One activity package is several versions behind the one installed in the current development environment. The bot retrieves credentials through an account owned by another team. A configuration file on a network share contains values that do not appear anywhere in the process documentation. One subprocess calls another automation whose production name differs from the name in the source project.

The bot itself ran successfully overnight.

Nobody in the room is prepared to change it.

The problem is no longer whether the automation works. It is whether the organisation still knows enough about the automation to alter it safely.

Before the change, the team has to reconstruct what is really running

A mature automation estate accumulates many kinds of debt. Some of it is visible: failing selectors, obsolete packages, duplicate bots, recurring incidents or growing support effort.

A more awkward form appears when a team cannot establish the blast radius of a change.

The ERP update forces that question immediately. Before touching the workflow, the team needs to know which deployed package is running, what that package depends on, which credentials it uses, whether any other processes consume the same components and what business behaviour has to remain unchanged after the release.

This is where RPA technical debt management stops being an inventory exercise and becomes a reconstruction problem.

Modern automation platforms increasingly expose those relationships because they are part of the production system, not peripheral documentation.

UiPath Orchestrator, for example, can inspect a process package and surface required assets, queues, triggers, connections, other processes and business rules. Missing required objects can prevent the process from executing. Even that dependency view has a boundary: for multi-layered process dependencies, Orchestrator documents only the first level automatically, leaving deeper dependencies to be identified separately.

Even where the platform knows a great deal about the deployed automation, understanding the complete system may still require reconstruction. In an older estate, far more of that work may depend on people.

The first bot opens into several other systems

The engineer follows the transaction bot backwards.

The scheduled process points to a particular package version. The package contains the expected workflow, but it also calls a reusable library. The library handles login and navigation for several automations against the same ERP environment.

Changing the library would therefore be cleaner than patching the individual bot.

It would also affect processes that are not part of the ERP release project.

A credential asset belongs to a technical account. Nobody currently in the meeting knows who approves changes to it. A downstream queue receives transactions from the bot and feeds another automation later in the day. The network-share configuration file contains a branch for a business unit that no longer appears on the process diagram.

The original request—move a selector after the screen changes—has turned into a map of dependencies that were always present but rarely needed to be considered together.

Routine production runs exercise familiar paths. A change forces the organisation to confront relationships that normal execution allows it to ignore.

UiPath’s Object Repository represents one attempt to make part of that problem more manageable. It centralises UI elements so they can be reused and modified from one place, and it is designed to improve selector reliability when applications change.

An estate built before those practices became normal can contain the opposite condition: the same screen element represented independently across many automations, each with its own history of repairs.

The ERP team sees one changed field.

The automation team may be looking at twenty interpretations of that field.

A production success log cannot reconstruct the decisions inside the bot

The support dashboard offers reassurance. Execution rates are healthy. Yesterday’s jobs completed. No unusual spike in exceptions appears.

Successful execution shows that the present automation can still operate under conditions it already knows. It says much less about whether a revised automation will preserve every behaviour that has accumulated around it.

One branch of the workflow retries an ERP transaction after a particular response code. Nobody remembers why the retry count is four.

Another branch skips an account lookup for one class of supplier. The process documentation does not mention the exception.

An old comment refers to a service incident number that is no longer accessible.

Removing any of these details might improve the code. It might also remove an accommodation introduced after a production failure several years earlier.

A 2024 report published by Springer, based on an RPA panel at the Business Process Management Conference, described an implementation in which a bot collected foreign-exchange rates from a website and entered them into SAP. After the website interface changed, the bot began entering incorrect data. The panel reported that diminished implementation knowledge contributed to the organisation taking a week to identify and resolve the problem. The same discussion raised broader concerns about process-knowledge loss and the need for RPA implementations that remain migration-ready as underlying systems change.

The source files may still exist while the explanation for why the automation behaves as it does has already dispersed across former employees, old incidents and undocumented operating decisions.

Ownership gaps become technical dependencies during maintenance

By the second week of the ERP investigation, the difficult questions have shifted away from selectors.

Who owns the technical account?

Who can approve a change to the shared library?

Which team knows whether the quarter-end automation still uses it?

Who can confirm that the network-share configuration is complete?

Who accepts the risk if an apparently obsolete branch is removed?

The bot has acquired organisational dependencies alongside its technical ones.

Automation platforms have had to address this problem explicitly. Microsoft’s guidance for Power Automate describes orphaned flows as flows that no longer have a valid owner and notes that they can fail when connections remain tied to the departed user’s account. Administrators can identify those flows and assign new ownership.

Microsoft also supports service-principal application users as flow owners so ownership does not depend on an employee remaining with the organisation.

The implementation details differ across automation platforms, but the maintenance risk is concrete: an identity that originally looked like an administrative convenience can become part of the production dependency chain.

So can a team mailbox, a spreadsheet maintained by one analyst, a Windows account, a manually created queue, an undocumented server path or an approval that everybody assumes another department owns.

Those dependencies usually surface when something changes.

The temptation to rebuild arrives before the team understands what it would erase

At this stage, somebody proposes the obvious solution.

The bot is old. The ERP interface has changed several times. The workflow has accumulated patches. Rebuilding it would be cleaner than continuing to repair it.

The argument is technically attractive, but the team still lacks a trustworthy account of the behaviour the replacement would have to preserve.

Rebuilding from the process document assumes the process document represents production behaviour.

Rebuilding from the source workflow assumes all significant behaviour is visible inside the workflow.

Rebuilding from interviews assumes the people currently running the operation remember every condition the bot has learned to accommodate.

The investigation has already shown why those assumptions are unsafe.

One configuration branch exists only in a file outside the project. A shared library carries behaviour used elsewhere. The retry logic has an undocumented history. A technical account crosses team boundaries.

A cleaner implementation could easily remove the very behaviour that made the old one reliable.

Before a rebuild starts, the organisation has to separate accidental complexity from operating knowledge embedded in years of fixes, workarounds and dependencies. Code cleanup comes later.

Recovering changeability means making hidden relationships explicit

The ERP project begins creating artefacts that the bot should probably have had years earlier.

The team records the deployed version and its dependencies. Shared components are traced to their consumers. Technical identities are assigned accountable owners. External configuration is moved into governed locations. Production behaviour that must survive the change is converted into test cases.

None of this is unusual in contemporary software delivery. It is simply unevenly present in older automation estates.

Power Automate’s solution-aware flows, for example, separate connection references from individual connections and use environment variables for values that differ between development, test and production. That reduces the amount of environment-specific information embedded directly into the flow. Solution-aware flows also support versioning and application-lifecycle-management practices.

UiPath has continued moving automation development in a similar direction. Its August 2026 Automation Ops releasemade Azure Repos integration in Source Control generally available, allowing automation projects stored in Azure Repos to be managed through the platform’s source-control capabilities.

Source control, dependency discovery and reusable UI definitions do not eliminate automation debt. Their value here is more specific: they reduce how much of the system has to be rediscovered before somebody can alter it with confidence.

The problem becomes harder as older RPA estates intersect with newer workflow, integration and agent architectures. Modernisation cannot safely begin from the assumption that an old bot is simple merely because its diagram is simple.

The ERP change finally becomes small again

The team eventually returns to the field that moved on the transaction screen.

By then, the actual edit is unremarkable.

They know which package is deployed. They have separated the shared library change from the bot-specific change. The service account has an owner. Downstream consumers have been identified. The strange configuration branch has been traced to a valid business condition. Test cases now capture the paths the team was initially afraid to disturb.

The release can still fail. Production changes always retain some uncertainty.

But failure is no longer mysterious. The team knows what it changed, what the change can affect, what behaviour should remain constant and where to look if that expectation proves wrong.

That is a more useful dividing line for an ageing automation estate than whether its bots are technically old.

Some old automations remain straightforward to modify because the organisation can still explain them.

Others become untouchable while they are apparently healthy because their operating knowledge has dispersed across packages, accounts, files, people and years of local fixes.

RPA technical debt becomes most restrictive at that point: not when the bot needs maintenance, but when every maintenance decision first requires an archaeological dig.

The ERP upgrade does not make the estate modern.

It does something more immediately valuable.

It makes one part of it understandable enough to touch again.