New Platform, Same Habits: Why Replacing the Tool Is Not Re-Channelling the Work

UK transformation programmes have a weakness for visible change. A new collaboration platform, a refreshed intranet, a migrated contact centre and a single sign-on portal all produce screenshots that can go into a board pack. They are tangible. They feel like progress. The harder question is whether the work itself has changed. Too often, it has not. The old habits simply move to a new interface.

This is the channel-swap trap. It is not a failure of procurement or technical delivery. It is a failure to distinguish between replacing a tool and re-channelling the work that flows through it. A migration can be completed on time, on budget and with high user adoption, while the organisation continues to make decisions in side chats, duplicate records in spreadsheets and route exceptions through personal inboxes. The stack is new. The operating model is not.

The swap looks like progress

There is a reason this pattern persists. Platform migrations are easier to fund, govern and report than workflow change. They have a clear scope, a vendor, a delivery date and a cutover plan. Workflow change is messier. It touches role boundaries, decision rights, performance measures and informal power structures. It requires managers to admit that the approved process is not the real process. That is uncomfortable, which is why many programmes quietly avoid it.

The result is a familiar sequence. The organisation runs a discovery phase that maps tools rather than work. It designs a target architecture around channels rather than conversations. It trains people on features rather than on new handoffs. It measures adoption by logins rather than by completed work. Six months later, the same complaints reappear: nobody knows where the decision was recorded, customer history is fragmented, and the fastest route is still a direct message to a colleague.

Three symptoms of the channel-swap trap

The first symptom is a business case dominated by licence consolidation. Saving money by retiring overlapping tools is a legitimate aim, but it is not a transformation strategy. If the only measurable benefit is a lower software bill, the programme is a procurement exercise with a change management wrapper.

The second symptom is a training plan that teaches buttons. Feature training is necessary, but it does not change behaviour. People need to know which conversation belongs in which channel, who owns the handoff and what good looks like at each step. If the training does not rehearse a real end-to-end case, it is unlikely to survive the first busy week.

The third symptom is a governance model that treats exceptions as defects. In reality, exceptions are where the work lives. A customer with a complex case, a supplier with an urgent query or a field engineer without connectivity will always create a workaround. If the new platform cannot accommodate the exception, staff will route around it. The programme then calls this resistance when it is actually evidence of poor workflow design.

Diagnostic questions before the next licence renewal

Before signing the next platform contract, UK leaders should ask a set of blunt questions. What work will stop when the old tool is switched off? Which conversations create obligations, and where will those obligations be recorded? Who owns the handoff between teams, and how will they know it has happened? Which decisions currently happen in side chats, and what will replace them? How will a new starter learn the real route through the organisation, not just the published one? What will managers measure to know that work has changed, rather than merely moved?

These questions are uncomfortable because they expose the gap between the official process and the operating reality. That gap is the point. A transformation programme that cannot describe it cannot close it.

A 90-day workflow-first plan

Days 1 to 30: Observe the work, not the tools

Start with a small number of high-value journeys: a customer complaint, a supplier onboarding, a field service job, a project decision. Shadow the people who do the work. Record every channel switch, every handoff and every point where someone says they will just message someone. Build a baseline of cycle time, rework and the number of places a record is held. Do not propose a solution yet. The objective is an honest map of current work.

Days 31 to 60: Redesign the handoffs

Bring together the people who own the work, the people who support it and the people who carry the risk. Redesign the handoffs before touching the technology configuration. Decide which conversations need an approved channel, which can remain informal and which should be retired altogether. Clarify decision rights. Agree what evidence must be captured and where. Then test the design against the exceptions that caused the most friction in the first month. If the new workflow cannot handle them, revise it now rather than after go-live.

Days 61 to 90: Pilot, measure and retire deliberately

Pilot the redesigned workflow with a real team on real cases. Measure the things that matter: time to resolution, number of channel switches, completeness of the record, rework rate and staff confidence. Compare them with the baseline. Then retire the old route deliberately, with a clear cutover date and a supported exception path. Do not leave the old channel open as a comfort blanket. If it remains available, the organisation will drift back to it.

What to tell the board

The board does not need a feature list. It needs a credible account of how work will change. That means naming the high-value conversations that will move, the handoffs that will be simplified and the measures that will show whether the change has stuck. It also means being honest about what will not change in the first 90 days. A workflow-first programme is narrower than a full platform migration, but it is more likely to produce evidence that the investment has altered how the organisation operates.

The channel-swap trap is not inevitable. It is a choice, made every time a programme treats a new platform as the destination rather than the substrate for a different way of working. In 2026, with budgets under pressure and hybrid working firmly established, UK organisations cannot afford to buy a new stack and keep the same broken communication habits. The test is not whether the tool has changed. It is whether the work has.