When New Software Leaves the Old Process in Place

A business introduces a new workflow, but staff continue updating the old spreadsheet because a manager still uses it for the weekly meeting. The software works. The organisation now performs part of the same task twice.

In this illustrative transition, the old record may contain information the new system does not provide, or it may still be the record a decision-maker trusts.

A transformation plan needs to address those reasons. It should explain which decisions will move, which records will become authoritative and how the business will handle work that does not fit the standard process.

Microsoft's guidance on business process management connects process analysis with implementation and ongoing review. That sequence matters because the operating change continues after the technical release.

The business should be able to describe the future work in plain terms. Who receives a request? What information do they use? Which decisions can they make? What happens when something is missing? How does the next person know that the work is ready?

If those questions remain unresolved, the new tool may preserve the same delays in a different interface. The scope of transformation therefore includes the operating decisions that make the technology useful, along with the software itself.

The software delivery team can configure a workflow and explain how it behaves. A business owner needs to decide how it fits the service, the staff's responsibilities and existing commitments.

Name that owner early. Give them authority to resolve process questions and obtain decisions from other teams. They should also have time to participate, rather than being added to the project as an honorary sponsor.

The owner does not need to make every decision alone. People performing the work hold knowledge about exceptions, timing and customer needs. Include them when defining the future process and reviewing whether it is usable.

DORA's guidance on user-centric software emphasises feedback from the people using a system. In an operating transition, that feedback helps distinguish a training need from a design or process problem.

For example, repeated workarounds may indicate that the new process cannot handle a legitimate case. Asking staff to comply more strictly will not resolve the missing capability. Conversely, a sound process may need clearer instructions or a changed management expectation before it replaces an old routine.

Keep the decision record practical. Explain what changed, why it changed and who owns the next action. Where a team must stop doing something, make that instruction explicit and ensure the conditions for stopping it are actually in place.

A transition owner gives those decisions a home across the period when the business is still learning how the new arrangement works.

The standard workflow should be clear, but it will not cover every request. Incomplete information, unusual customer needs and conflicting records are part of ordinary business operation.

Decide how those cases enter the process. Staff should be able to preserve context, identify the issue and obtain an authorised decision. A workflow that simply rejects the case may push work into email or private spreadsheets, where the business has less visibility.

Distinguish an exception that can be handled within existing rules from one that requires a commercial choice. An employee may correct a missing contact detail but need approval to change an agreed service. The process should make the boundary understandable.

Include the effect on customers. A request awaiting a decision needs an appropriate status and communication route. Staff should not have to improvise a promise because the internal process provides no explanation.

These design choices may reveal that the initial scope is too ambitious. A staged transition can be sensible if the business can state which work uses the new process and which work remains elsewhere.

The boundary needs to be explicit. Ambiguity about where a request belongs can create duplicate work or leave it unowned. The team should know how to identify the governing record and how to transfer a case when its circumstances change.

Training requires time that would otherwise be used for ordinary work. A plan that ignores that time can leave staff expected to maintain output while learning unfamiliar tasks and repairing early mistakes.

The OECD's 2025 D4SME survey, covering platform-using respondents in ten OECD countries, identifies training time among the barriers reported by SMEs. The practical response is to allocate learning capacity rather than assuming it will appear around the edges of the working day.

Teach the tasks people need to perform. A tour of every menu may be less useful than completing a realistic request, handling a common exception and recovering from an error.

Use the actual devices, permissions and information involved. A demonstration performed with administrator access may conceal difficulties ordinary users will encounter. Instructions should be available in a form the team can consult while working.

Identify where questions go after the initial training. Early support should help the organisation find recurring problems, not leave each employee to devise a separate workaround.

Different roles need different preparation. A frontline user, a manager reviewing work and the person administering the system will not all need the same depth. Match the learning to the responsibility the person is expected to carry.

Capability develops through use, so leave room to revise the guidance as the team encounters real cases.

Running old and new processes together can reduce uncertainty during a transition. It can also double work and create disagreement about which record governs a decision.

If parallel operation is necessary, explain its purpose. Is the business comparing results, preserving a recovery option or moving different groups in stages? The answer should determine what is checked and how long the arrangement remains useful.

Define the conditions for retiring the old route. These may include successful completion of important tasks, resolved data discrepancies, trained operating owners and a tested recovery plan appropriate to the service.

Keep control of corrections during the overlap. If both systems can be edited, establish how changes are reconciled. If one is read-only, make that clear. Avoid leaving staff to infer which version should be trusted.

Retirement includes more than switching off software. Reports, meeting habits, approval routes and customer instructions may still depend on the old process. Identify those dependencies before removing the system they reference.

A proportionate recovery route is still important. The business should know what would justify slowing or pausing the transition and how it would preserve work already completed. Those decisions are easier to make when planned before an incident.

The aim is an orderly move to a usable operating arrangement, with duplicate work removed once it has served its purpose.

Adoption measures should show whether people can perform the intended task. Login counts and training attendance provide limited evidence by themselves.

Review completion, errors, repeated entry, unresolved exceptions and the need for informal assistance. Connect those observations to the customer or operating outcome the project was intended to improve.

When the result differs from the expectation, investigate the cause. The design may need revision, a responsibility may be unclear or the organisation may still be rewarding the old behaviour. Each calls for a different response.

The change takes hold when staff can complete the new process, resolve its exceptions and retire the unnecessary work it replaced. Judge the transition at that point, with the people who must keep the service running.