ProcessManaged Services

Moving a business function to a managed service without disrupting it

A transition moves live work, the knowledge behind it and sometimes the people who do it from your organization to a provider. Transitions usually fail because undocumented work surfaces after cutover. This plan expands the Discover, Design, Build and Migrate phases into a sequence with outputs, acceptance gates and staff-transfer checks, and starts the exit plan on day one.

Reviewed 6 min read

On this page
  1. What a transition has to protect
  2. Transition timeline from discovery to steady state
  3. Seven stages and what each one hands over
  4. Staff-transfer rules that may apply to the people involved
  5. Where transitions most often break
  6. Writing the exit plan while the knowledge is fresh
  7. Questions and answers
  8. Sources

What a transition has to protect

Three things are at risk when a function changes hands. Service continuity: customers, suppliers and regulators should not notice the move. Knowledge: the rules people apply from memory, the workarounds and the quirks of each seasonal peak. People: those who move, those who stay to oversee the provider, and those whose roles change.

When the provider will use AI to do part of the work, add a fourth: evidence. The baseline of volumes, cycle times and error rates captured before the move is the only way anyone can later tell whether automation improved the service or quietly degraded it. ColdAI's managed services start with a Discover phase for this reason, before Design, Build and Migrate4.

Transition timeline from discovery to steady state

01Discover and baseline02Design the targetservice03Shadow and reverseshadow04Build and test05Parallel run06Cutover and hypercare07Steady-state operation
  1. Discover and baseline

    Map the process as it actually runs and measure the starting point.

  2. Design the target service

    Split work between software and people, and fix controls and service levels.

  3. Shadow and reverse shadow

    Transfer knowledge until the provider can run each variant under observation.

  4. Build and test

    Configure automation and test it against a library of real edge cases.

  5. Parallel run

    Both teams process the same work and outputs are compared against written criteria.

  6. Cutover and hypercare

    Switch over with a rollback point, then run heightened checks until stable.

  7. Steady-state operation

    Normal service levels and governance apply.

Conceptual sequence of a transition. In practice stages overlap, and their length depends on the process; it is not a measured timeline.

Seven stages and what each one hands over

  1. Map the process as it really runs

    Combine process mining on system logs, interviews and desk-side observation. Record volumes by day and month, peaks and exception types, and hunt for undocumented work: private spreadsheets, side inboxes, favours to other teams and manual checks an auditor relies on.

    Output
    Process inventory, volume baseline and SOP gaps
    Owner
    Client process owner with the provider's transition lead

  2. Agree the target service model

    Decide which steps software performs and which people keep, the controls around both, the reports you will receive and the roles your retained team will hold. Fix the service level indicators and how their baseline is measured.

    Output
    Service description and control matrix

  3. Transfer knowledge by shadowing

    Provider staff sit with your team as they work, write up the procedures they observe and collect unusual cases into a test library. Every exception your experts can recall from the last year belongs in that library.

    Output
    Validated procedures and an edge-case library

  4. Reverse shadow and build

    The provider now does the work while your experts watch and correct. In parallel, automation is configured and tested against the edge-case library rather than tidy sample data.

    Output
    Sign-off per process variant that the provider can run it

  5. Move access and open items

    Grant least-privilege access with credentials your organization owns, migrate open items and the history the service needs, and switch on logging before any live processing.

    Output
    Access register and a reconciled open-item list

  6. Run in parallel against written criteria

    Both teams process the same work and outputs are compared item by item. Typical criteria: sampled quality at or above baseline, no unexplained differences in totals, exceptions handled within agreed times, across consecutive cycles that include a month-end or peak.

    Output
    Signed acceptance record

  7. Cut over and stabilize

    Switch with a defined rollback point, then run hypercare: daily calls, heightened sampling and your experts on hand. Agree in advance the evidence that ends hypercare; the guides to cutover planning and hypercare cover both in detail.

    Output
    Hypercare exit report

Staff-transfer rules that may apply to the people involved

In the UK, the Transfer of Undertakings (Protection of Employment) Regulations 2006 cover service provision changes, which include outsourcing an activity to a contractor where an organised grouping of employees has the principal purpose of carrying it out for the client1. Employees assigned to that grouping transfer to the provider on their existing terms, and dismissals because of the transfer are automatically unfair unless there is an economic, technical or organisational reason entailing changes in the workforce.

The outgoing employer must give the incoming one employee liability information not less than 28 days before the transfer2, and Regulation 13 imposes duties to inform and consult employee representatives. In the EU, Directive 2001/23/EC protects employees' rights when an undertaking, business or part of one transfers3; national laws implement it, and whether a particular outsourcing counts as a transfer depends on national law and case law.

Where the service design assumes automation will absorb work over time, say so during consultation and plan redeployment honestly. Announcing no impact and reducing roles later damages the trust the transition depends on.

Where transitions most often break

Undocumented work surfaces after cutover

Early signalA growing 'other' category in exception reports during hypercare.

MitigationWalk through month-end and year-end tasks explicitly in discovery, and keep your experts available until hypercare ends.

Knowledge leaves with people

Early signalKey staff resign soon after the announcement.

MitigationRecord knowledge early, agree retention arrangements for critical experts and sequence the announcement after shadowing has started.

Parallel run declared complete too early

Early signalThe run has not yet covered a peak or a period close.

MitigationMake a peak cycle part of the acceptance criteria, even if it lengthens the run.

No baseline to judge the new service against

Early signalDebates about whether quality has fallen rely on anecdote.

MitigationMeasure the baseline in discovery and keep the raw data, not just the summary figures.

Writing the exit plan while the knowledge is fresh

The best time to plan an exit is during transition, when both sides are documenting everything anyway. An exit plan should list the procedures, automation configurations, prompts and model versions, data and logs that would move to you or a successor; state who owns automation built for your service; fix the format and timing of data return; and commit the provider to transition assistance. Test it with a walkthrough before the first renewal.

For EU financial entities, exit strategies for ICT services supporting critical or important functions are a legal requirement rather than good practice; the guide to DORA and outsourcing rules sets out what the contract needs. When the exit eventually runs, the direction reverses: the software handover checklist covers what an in-house team should receive when it takes a system back.

Questions and answers

How long does a managed services transition usually take?

It depends on the number of process variants, how well they are documented and when the peaks fall. The firmest rule is that the parallel run should cover at least one full business cycle including a month-end or seasonal peak. Shortening the run saves weeks on paper and often costs more after cutover.

What is the difference between shadowing and reverse shadowing?

In shadowing, the provider's staff watch your team do the work and document it. In reverse shadowing, the provider does the work while your experts watch and correct. The first transfers knowledge; the second proves it has transferred, which is why sign-off should follow reverse shadowing rather than shadowing.

Does TUPE apply if the provider will use AI rather than people?

It can. The service provision change test looks at the activities and the organised grouping of employees before the change, not mainly at how the provider will do the work afterwards. Where the activities stay fundamentally the same, a new method alone does not obviously take a transfer out of scope. The facts matter, so take advice early.

What should our organization keep after the transition?

A small retained team: a service owner accountable for the outcome, process experts who can judge quality, owners for the controls the service operates, and someone who manages the commercial relationship. Without them you cannot challenge the provider, approve changes on evidence or exit in an orderly way.

Sources

  1. The Transfer of Undertakings (Protection of Employment) Regulations 2006 — legislation.gov.uk · checked 10 October 2026
  2. TUPE 2006, Regulation 11: notification of employee liability information — legislation.gov.uk · checked 10 October 2026
  3. Council Directive 2001/23/EC on safeguarding employees' rights in the event of transfers of undertakings — EUR-Lex · checked 10 October 2026
  4. Managed Services: six-phase methodology — ColdAI

More in Managed Services

Back to Managed Services

Next step

Plan a transition around your busiest business cycle

Tell us which function you are considering moving, when its peaks fall and where the process is documented. We will outline a transition sequence, the evidence to collect first and the acceptance criteria to agree before any parallel run.

Plan a transition