Migrating a Book of Business

From WFM Labs

Part of the Planning Week chain · previous: The Definitions Register · next: Placement Engine Build Path Migrating a book of business is the movement of one client's or one segment's work from one servicing or workforce platform to another, or from one planning owner to another, in phases, with the planning function sizing each phase before it lands. It matters because a migration changes the object being measured while the reports keep their names, so that a plan carried across the change reads as measured when it is asserted, and the shortfall appears where the reports do not look. The page produces the book-migration runbook (BM), one per book, and is worked in a session with Wiki:Packs/Book Migration (CP-OPS-004).

The runbook is walked on Day 3 afternoon as the second chapter of Technology Migration Plan for a Workforce Function, because a migration is the clock that gives The Definitions Register a date. In the worked example the migration means the corporate client book's phased servicing-platform migration and is referred to only that way; the runbook applies equally to a book moving onto a fresh instance of the short-term WFM engine, the case Systems Administration for WFM Platforms carries.

What a migration changes

A migration is planned by people who know the sending platform well, on the history that platform produced, and the plan is usually right for the platform it was built on; the difficulty is structural rather than a matter of care. Platform Migration as a Definitional Forcing Function gives the object inventory a platform migration forces into shared definition (gates or queues, skills, pools, activity states, intents, time and calendar objects) and is cited rather than re-listed; a book cannot be configured on the receiving platform until those objects have one definition. Asynchronous-to-Synchronous Channel Conversion gives the second change: when the channel changes with the platform, the old channel's history is not a baseline for the new one, because a conversation and a session are different units and handle time on the two sides is two quantities sharing a name. The rule this page carries from both is the carry rule of Human Gates and Number Grades: nothing carried across a channel, platform or cohort change is measured in the new state; it is asserted until the new state measures it.

A migration therefore has two kinds of history. The layer beneath the channel transfers: the intents customers bring, when they first reach out, the seasonality and the population. Everything above it (contacts per intent, handle time, concurrency, abandonment, the staffing ratio) is a property of the receiving side and is unobserved until it has run.

The runbook

The runbook has eight steps, and the order is the content.

Step What is done What it produces Grade of what it produces
1 Definitions first. The object inventory is checked against The Definitions Register: every object the receiving platform will hold cites an entry; every metric the phase will be sized on cites an entry The inventory status: settled, mapped, or open with an owner Established or Open per object
2 The measurement model settled before the next phase. For each sized metric, the receiving platform's instrument and what it measures are stated in the register; where two readings exist (a handle time as elapsed time or as agent work), both are named and the sizing uses the one the entry adopts The measurement model, dated Established once signed; the phase cannot be sized before it
3 The baseline, like for like. The sending platform's figures are recomputed on the population that is moving, on the register's definition, over a stated window The like-for-like baseline [M] on the sending platform; [A] as a prediction of the receiving one
4 Delivered hours read, never assumed. Scheduled, staffed and productive hours by cohort and tenure from the short-term WFM engine's supply data, not from a staffing ratio The supply ledger for the migrated population [M]
5 The phase sized as a range with its assumption register. Workload in hours by channel (work arriving × time per piece ÷ hours delivered), with every carried assumption labeled carried and graded [A], every estimate a range [E] The sizing, its register, and the seats it implies [E] at best, because the register is
6 The phase gate. The phase decision is taken only when steps 1 to 5 are done; the record names what would change the sizing and who re-runs it The phase decision, recorded with the sizing cited A decision; not a number
7 The schedule as a change-control item. The phase date enters the change-control board's log and the collision calendar; a moved date re-opens step 5 The change-control record —
8 Adapters read and write files first. The receiving platform's forecast load and the sending platform's actuals cross as stamped files with a definitions mapping and a signature, before any interface The mapping file; the crossing log —

Step 6 is the phase gate: the migration's own acceptance test for the next phase. It is not the acceptance gate of Process Standardization Lifecycle, which admits a process document to the standard; the phase gate admits a phase to the calendar, and it passes when the measurement model is settled, the baseline is like for like, the delivered hours are read and the sizing carries its register. A phase that lands without the gate has not been decided; it has been scheduled.

Two standing rules sit beneath the steps. The planning function is in the resource call for every phase, so that the capacity consequence of a phase is stated before the decision rather than discovered after it; where that has not been the practice, the runbook is the instrument that makes it one. And the migration schedule is a change-control item, owned by the board that owns configuration (Systems Administration for WFM Platforms), because a phase date is the largest single configuration change in most quarters.

A third rule governs who may hold both jobs. One seat can own the function's forecasting, scheduling, real-time and placement standards and lead the migration of its largest book, because the two roles change different objects through different instruments: the standard changes only through the acceptance gate of Process Standardization Lifecycle, which admits a process document; the migration changes only through the phase gate above, which admits a phase to the calendar. What the arrangement must not produce is a standard written to fit a phase. The test is procedural rather than personal: if a phase needs a definition the register does not hold, the register is amended through its own change control and signed, and the phase waits for the signature — a migration that cannot wait is a migration whose sizing was never gated.

The like-for-like ratio rule

A migration is often sized on a ratio: contacts per transaction, contacts per user, cases per booking. A ratio is a convenient summary and a poor baseline, for two reasons the register makes visible.

The first is composition. The ratio of a whole book, most of which has not moved, is not the baseline for the population that has, because the moved population may have run a different ratio on the sending platform all along; a segment that was always high-contact will show a "rise" at cutover that is its own history. The rule is that a baseline is computed on the population that is moving, on one definition, over a stated window, and that only the moved population's own before-and-after difference may be called a change. The demographers' decomposition of a difference between two rates into a within-group component and a composition component is the general form, and it is applied on Hypothesis Testing with Agent Teams to the series example.[1]

The second is definition. The two sides of a ratio may count different units: a transaction on the receiving platform may include lines the sending platform counted as one; a contact on a session channel may be a fragment of what the sending channel counted as one conversation. A ratio whose numerator and denominator have each changed definition at cutover cannot be compared to its predecessor at all, and the register's carry rule marks it asserted. The series example's two definitions of contacts per transaction, CPT-01 at 0.42 [M] and CPT-02 at 0.31 [M] on the same days, are the trap in its simplest form.

Workload, not ratio

The runbook sizes a phase in hours by channel and never on a ratio alone: work arriving, times time per piece, divided by the hours a full-time equivalent delivers after shrinkage and at the target occupancy, with every input graded and the computed figure inheriting the weakest grade.[2] The reason is that a migration usually moves handle time as much as volume, and a ratio hides it. A receiving platform on which agents identify customers differently, or on which a conversation runs end to end in one channel, changes time per piece for the same intent; a cohort new to the platform may show a level shift with no learning curve, a structural driver the plan must carry, or a curve, a transitional one it must not carry beyond its window. Handle time on a session channel adds the definitional half: under an elapsed-time definition at a concurrency of two, the phase's chat workload in hours is about twice what the agent-work definition gives [C], and which of the two the platform reports is the first question the measurement model settles.

Where the volume side is a ratio, the runbook replaces it with a difference the audience can read directly: the net contacts created for the migrated population, on one definition, against the population's own baseline. Where a phase must be sized before its measurement model is settled, the sizing is a range wide enough to hold both readings, and names the reading that would narrow it.

Adapters, and the two things they refuse

The receiving platform's forecast load and the sending platform's actuals cross the boundary as files first, per Integration Agents: a stamped file in the receiving system's column names, a header naming the definitions mapping, and a signature block. The adapter refuses a field that maps to no register entry, and refuses an unsigned version. During a migration the first refusal is the more valuable: the rejection log on the first phase is the list of objects whose definitions were never settled, produced by the mechanism rather than by a review; the pattern is the integration literature's message translator with a signature rule added at the boundary.[3] Because the file is the version, the sizing a phase was decided on can be found later as the version the decision cites, which a refreshed spreadsheet cannot give and which the forecasting-evaluation literature treats as a precondition for judging a forecast honestly.[4]

Worked example

The corporate client book of the series example: phase 1 of the migration live Monday 2 March 2026; phase 2, which doubles the migrated population, Monday 30 March; the phase 2 plan signed Friday 27 March at about 310 FTE [E], on voice handle time 452 seconds [M] measured since go-live rather than the 412 seconds [A] carried from the sending platform's plan, shrinkage 30 percent [E] (28–32) and an occupancy target of 85 percent [A]. On Day 3 afternoon, Wednesday 22 April 2026, the room opens runbook BM-001 for the book's next phase. Step 1 finds the object inventory settled for gates and skills and open for intents. Step 2 names the two readings of chat handle time on the receiving platform and adopts agent work as the register's definition, with elapsed time held as a second field. Step 3 recomputes the baseline on the migrated population alone, on CPT-01, and retires the legacy report's CPT-02. Step 4 reads productive hours by cohort from the short-term WFM engine; step 5 sizes the next phase as a range, with the partner cohort's handle time carried at 470 seconds [M] as structural per register row Q-004 and the in-house cohort's curve as transitional. Step 6 sets the phase gate for the June cycle's lock, pencils down business day 7, Tuesday 9 June 2026. Step 7 enters the phase in the change-control log. On Day 4 morning D-13 assigns the migrating book to the planning-loop team, already at its pilot rung when the week opens, so that the runbook's ledgers are the pilot's first book and a second book's migration becomes the clone's test.

The artifact this page produces

The book-migration runbook (BM), one per book. One filled example row:

Book Sending platform or owner Receiving Object inventory status Measurement model settled Delivered hours read (source) Phase Sized range Assumption register Change-control item Adapters
BM-001, the corporate client book The legacy servicing platform; the in-house planning seat The new servicing platform; the same seat, with the partner cohort added Gates and skills settled; pools mapped; intents open (owner: the definitions owner) Wed 22 Apr 2026 (chat handle time as agent work; elapsed held as a second field) Short-term WFM engine supply extract, by cohort and tenure, 2 Mar–17 Apr 2026 [M] Next phase; gate at the June lock, Tue 9 Jun 2026 Voice at 470 s partner [M] / in-house curve [E]; FTE as a range on shrinkage 28–32 percent [E] Twelve rows; two carried and labeled [A] Logged Day 3; a moved date re-opens sizing Forecast file out and actuals in as stamped files; mapping v1; unsigned versions refused

Produced in a working session with Wiki:Packs/Book Migration (CP-OPS-004); the filled set is part of blueprint v0.1.

What would change this

The page claims that a phase sized on figures carried across the migration, or on a whole-book ratio, will be wrong in a direction and by an amount the inherited reports do not show. The observation that would overturn it is a migration, with a channel or cohort change, whose carried plan was confirmed by the receiving platform's first measured period within the plan's own stated tolerance, without a measurement model settled beforehand. If that migration exists and its planners can show the reconciliation, the runbook's steps 2 to 5 are prudence rather than necessity and the phase gate should be lighter.

How this connects

Maturity Model Position

Four scales on this wiki use the word level; the launch page states which is which. This page uses the WFM Labs Maturity Model™'s Levels 1–5. Sizing a phase by hand on a like-for-like baseline with a written assumption register is Level 2 work on the WFM Labs Maturity Model™ done with Level 3 discipline; the channel-conversion page notes that Level 2 is where a channel conversion is most dangerous, because the reporting is rich enough to reassure; the same logic applies to a platform migration, and this page carries that as an inference. The runbook run by an agent team over living ledgers, with adapters refusing unmapped fields, is the Level 3 form; a phase sized as a distribution over the two handle-time readings rather than a range is Level 4.

See Also

References

  1. ↑ Kitagawa, E. M. (1955). "Components of a Difference Between Two Rates". Journal of the American Statistical Association 50(272), 1168–1194. doi:10.1080/01621459.1955.10501299.
  2. ↑ Koole, G. (2013). Call Center Optimization. MG Books. ISBN 978-90-820179-0-8.
  3. ↑ Hohpe, G., & Woolf, B. (2003). Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Addison-Wesley. ISBN 978-0-321-20068-6.
  4. ↑ Croushore, D., & Stark, T. (2001). "A real-time data set for macroeconomists". Journal of Econometrics 105(1), 111–130. doi:10.1016/S0304-4076(01)00072-0.
Retrieved from "https://wiki.wfmlabs.org/w/index.php?title=Migrating_a_Book_of_Business&oldid=4731"