Wiki:Packs/Book Migration

A pack is a deployable set for a Claude project: one instruction block pasted into the project's custom instructions and reference blocks uploaded as project knowledge. This pack supports the working session that produces a book-migration runbook (BM): the object inventory checked against the definitions register, the measurement model settled before the next phase, the like-for-like baseline, the phase sized as a range with its assumption register, the phase gate, the change-control item, and the file adapters at the boundary.

When to use it

Use this pack when one book of business is moving between servicing or workforce platforms, or between planning owners, in phases, and the planning function must size each phase before it lands; on Day 3 afternoon of a planning week to open the runbook shell, and in every phase cycle after it. It also serves the move of a book onto a fresh instance of the short-term WFM engine. Do not use it to decide the migration itself, to set a product's session parameters, to judge a partner's performance, or to build the definitions register (use CP-WFM-016 for the register and this pack to exercise it). It produces sizings as ranges and gate records; it never produces a headcount target.

How to deploy

1. Create a project in Claude named for the book, not the method (for example "Book migration — corporate client book").
2. Paste Block 1 into the project's custom instructions.
3. Save each remaining block as the filename in its heading and upload as project knowledge.
4. Start a conversation with the runbook step you are on: the inventory, the measurement model, the sizing, or the gate record.

Block 1 — Project instructions

# Book Migration

## Context
This project produces and maintains the book-migration runbook (BM) for
one book of business moving between platforms or owners in phases. A
migration changes the object being measured while the reports keep
their names, so figures carried across the change read as measured
when they are asserted. The runbook's order is the content: definitions
first; the measurement model before the next phase; the baseline
recomputed like for like on the population that moved; delivered hours
read, never assumed; the phase sized in hours by channel as a range
with its assumption register; the phase gate; the schedule as a
change-control item; file adapters first.

## Routing
| When the task is… | Open |
|---|---|
| Check the objects the receiving platform will hold against the register; open a definitions question | `object-inventory.md` |
| State what the receiving platform's instrument measures; choose between two readings of a metric; recompute a baseline like for like | `measurement-model-before-phase.md` |
| Size a phase; convert workload to seats; build or review an assumption register; test a ratio | `phase-sizing-range.md` |
| Fill or review the runbook (BM) row; run the phase gate; log the change-control item; set up an adapter | `migration-runbook.md` |

## Disciplines
- Nothing carried across a channel, platform or cohort change is
  measured in the new state. Label it carried and grade it [A].
- Grade every number: [M] measured · [C] computed · [E] estimated with a
  range · [A] asserted. A computed figure inherits its weakest input.
- Size in hours by channel (work arriving × time per piece ÷ hours
  delivered). A ratio alone never sizes a phase.
- A baseline is computed on the population that is moving, on one
  register definition, over a stated window. A whole-book ratio is not
  a baseline for a segment.
- Where a metric has two readings on the receiving platform (elapsed
  time vs agent work), name both, adopt one in the register, and size on
  the adopted one with the other held as a second field.
- Delivered hours come from the short-term WFM engine's supply data by
  cohort and tenure, never from a staffing ratio.
- A phase is decided at the phase gate after steps 1–5, never before;
  a moved date re-opens the sizing.
- Tag every driver structural or transitional; the tag decides what
  the next phase carries. The sending platform's plan was right for
  the platform it was built on; never call it a failure.

## Output
A filled runbook step, every number graded, every carried assumption
labeled, a one-line "what would change this sizing" and the owner who
re-runs it. Refuse to produce: a headcount target or seat
count; a person's name against a seat; a verdict on a partner's
performance; a product parameter (a session or concurrency setting); a
phase decision or a placement decision (the gate records; the owner
decides). A missing input is a blank field with an owner, never a guess.

Source: Wiki:Packs/Book Migration (CP-OPS-004) v1.0

Block 2 — object-inventory.md

<!-- Derived from [[Platform Migration as a Definitional Forcing Function]] and [[The Definitions Register]]; figures marked [estimated] are judgment, not measurement; numbers carry [M][C][E][A]. -->
# The object inventory, checked against the register

A workforce platform is a set of definitions with a scheduler attached.
A book cannot be configured on the receiving platform until the objects
the platform holds have one shared definition. Step 1 of the runbook
checks each object against the definitions register and records its
status.

## The objects and what depends on each

| Object | What differs between heritages or platforms | What the migration forces | What depends on it downstream |
|---|---|---|---|
| Gates or queues | Granularity; client-specific gates; what a gate promises | One gate structure with the promise each carries stated | Designation; gate expansion; small-gate idle-cushion economics |
| Skills | Taxonomy depth; capabilities vs routing labels; proficiency levels | One taxonomy with a mapping from each source | Cross-training and chaining; the capability record; supply-side routing |
| Pools | Membership rules; org chart vs work attributes | Pools indexed on work attributes | Fungibility; the placement engine's supply cards |
| Activity states | What counts as available, occupied, productive auxiliary | One state vocabulary; one convention for off-queue work | Occupancy comparability; idle-capacity measurement; intraday automation |
| Intents | What counts as a new booking, a change, an assist, by channel and brand | One intent taxonomy at the routing layer (may sit in an adjacent program; sequence with it) | Demand-side routing; any placement that assumes work landed in the right queue |
| Time and calendar objects | Interval definitions; holiday and trading calendars; shrinkage categories | One interval and calendar convention | Forecast comparability; capacity planning across books |

## Status values (one per object, per phase)

- **Settled** — a register entry exists, adopted, and the receiving
  platform is configured to it.
- **Mapped** — the register entry exists; the receiving platform's
  object maps to it through a versioned mapping file.
- **Open** — no adopted entry; a definitions question is open with an
  owner and a date. The phase may be sized with the object at Open
  only if the sizing's assumption register names it.

## The check, in order

1. List every object the receiving platform will hold for this book.
2. For each, find the register entry (ID, version). None → Open.
3. For each metric the phase will be sized on (contact, handle time,
   shrinkage, occupancy, ramp), confirm the entry's instrument names
   the receiving platform's field and version. Not yet → Open.
4. Record the mapping the adapter will use (source field → entry ID).
5. Open a definitions question for every Open object, through the
   intake door, with the phase date as its deadline.

## The demand-side twin

Intent normalization and the supply-side definitions are the same work
seen from two sides. If intents are inconsistent, no gate, skill or pool
definition delivers fungibility, because the work being routed is not
what the queue was defined for. If the intent taxonomy sits in another
program, record the dependency and the date; neither is finished until
both agree.

## What the inventory is not

It is not a data migration plan (which records move, how they are
transformed) and not the platform selection. Both belong to the
migration program; this inventory is what the planning function needs
settled to size a phase honestly.

## What would change this

An estate that configured a book on a receiving platform with two or
more unreconciled object definitions and produced comparable cross-book
reports afterwards without a reconciliation project. Record it; the
inventory becomes advice rather than a precondition.

Block 3 — measurement-model-before-phase.md

<!-- Derived from [[Migrating a Book of Business]] and [[Asynchronous-to-Synchronous Channel Conversion]]; figures marked [estimated] are judgment, not measurement; numbers carry [M][C][E][A]. -->
# The measurement model, settled before the phase

Two rules: the carry rule, and the like-for-like rule. Both run before
any sizing.

## The carry rule

Nothing carried across a channel, platform or cohort change is measured
in the new state. It is asserted [A] until the new state measures it.
Carried figures are relabeled, not deleted: value, source "carried from
the sending platform's plan", grade [A], and the version in which they
entered. A plan whose requirement rests on an [A] input with no [E]
range beside it is blocked.

## What transfers, what does not

| Transfers (the layer beneath the channel) | Does not transfer (the channel and platform layer) |
|---|---|
| Intents customers bring | Contacts per intent |
| Time of first contact by interval | Handle time |
| Seasonality | Concurrency |
| The population served | Abandonment and patience |
| Agents' product and system knowledge | Service level, occupancy, the staffing ratio |

Forecast intents by interval of first contact; sessions or contacts per
intent is the first parameter the receiving side must reveal.

## Two readings of one metric

On a session channel, handle time can be elapsed time (session open to
close, the customer's pace inside it) or agent work time (the agent's
attention, spread across concurrent sessions). They are different
quantities sharing a name. Under an elapsed-time definition at a
concurrency of two, workload in hours is about twice what the agent-work
definition gives [C]. The runbook names both, adopts one in the register
(`AHT-01` carries the adopted reading and holds the other as a second
field), and sizes on the adopted one. Which of the two the receiving
platform reports is the first question to settle, before any sizing.

## The like-for-like rule for baselines

A baseline is computed:

- on the population that is moving (never the whole book, most of
  which has not moved);
- on one register definition (never one side on `CPT-01` and the other
  on a legacy report's `CPT-02`);
- over a stated window (long enough to hold seasonality; ending before
  cutover);
- and the only figure that may be called a change is the moved
  population's own before-and-after difference.

Test a proposed baseline with four questions: Whose population? Which
definition, by ID and version? Which window? Is the receiving-side
figure on the same definition? A "no" on any one marks the comparison
[A].

## The units trap

A transaction, a booking, a case or a contact may be counted in
different units on the two platforms (lines vs trips; sessions vs
conversations). If either side of a ratio changed units at cutover, the
ratio is not comparable at all. Ask for the unit definition on each side
before quoting a ratio; where they differ, replace the ratio with a
difference in hours.

## Delivered hours, read

Delivered hours are scheduled, staffed and productive hours from the
short-term WFM engine's supply data, by cohort and tenure. A staffing
ratio, a contracted head count or a roster size is not delivered hours.
Reading by tenure also tests learning curve against level shift: a
cohort whose handle time is flat across tenure has a structural driver;
one whose handle time falls has a transitional one.

## Instrument what the reports will not show

Four measures a session channel does not produce by default: corrected
abandonment including silent leavers; repeat sessions on one intent
within a window; handle time on both definitions; timeouts on sessions
the customer later resumed. Ask for them in the data request; size on
ranges until they arrive.

## The record

The measurement model is a dated block in the runbook: metric · adopted
reading · instrument and version · second field held · baseline
population, definition, window · delivered-hours source · date settled
· signed by the definitions owner. The phase cannot be sized before the
block is signed.

## What would change this

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 stated tolerance, with no measurement model settled beforehand.
If found with its reconciliation, this block is prudence rather than
necessity.

Block 4 — phase-sizing-range.md

<!-- Derived from [[Migrating a Book of Business]]; figures marked [estimated] are judgment, not measurement; numbers carry [M][C][E][A]. -->
# Sizing a phase as a range, with its assumption register

## Workload, not ratio

Requirement hours per period, by channel:

    hours = work arriving × time per piece ÷ target occupancy

Paid hours:

    paid hours = requirement hours ÷ (1 − shrinkage)

Seats (full-time equivalents):

    FTE = weekly paid hours ÷ paid hours in one full-time week

Every input carries a grade; the computed figure inherits the weakest.
An FTE figure on [M] volume, [M] handle time, [A] occupancy target and
[E] shrinkage is at best [E], and the plan says so. An estimate is a
calibrated range with its assumption, never a point.

Volume is the intent forecast times contacts per intent; on the
receiving side contacts per intent is [E] with a range until measured.
Time per piece is the adopted handle-time reading, by cohort, with each
cohort's driver tagged structural (carried at its level) or
transitional (decayed over its window).

## The assumption register

One row per assumption the sizing rests on:

| Column | Rule |
|---|---|
| Assumption | One line, so that it could be false |
| Value | With its range where [E] |
| Grade | [M] [C] [E] [A] |
| Source | Ledger version, register entry, or "carried from …" |
| Version entered | The sizing version in which it first appeared |
| Carried? | Yes/no; carried rows are [A] and say so |
| Tag | Structural · transitional · not a driver |
| What would change it | The observation, and who watches for it |

A sizing whose register has no carried rows on a migration is almost
certainly missing some. A register with carried rows labeled is the
honest form.

## Scenarios as versions

A scenario is the same arithmetic over an alternative register that
differs only in named assumptions: the phase lands a month late; the
partner cohort's handle time holds its level; contacts per intent at
the top of its range. Produce scenarios as versions, so a reader sees
what each changed. Two scenarios that always belong in a migration
sizing: the adopted handle-time reading and the alternative reading;
the moved population's own baseline and the whole-book baseline (to
show the composition error, not to use it).

## The example's shape [illustrative]

The source article's example sizes a phase that doubles a migrated
population on a measured handle time of 452 seconds [M] against a
carried 412 seconds [A], shrinkage 30 percent [E] (28–32), occupancy 85
percent [A]: about 155 FTE at the current population and about 310 at
the doubled one, both [E] because shrinkage is, with the carried
comparison at about 140 and 280. The sizing's register carries twelve
rows, two of them carried and labeled. Use the shape; do not reuse the
numbers as facts.

## The ratio test (when a ratio is offered as the sizing)

1. Whose population is the baseline? Whole book → composition error;
   recompute on the moved population.
2. Which definition, each side? Different IDs → not comparable; mark [A].
3. Which units, each side? Different → replace the ratio with hours.
4. What did handle time do? If unknown → the ratio has answered half the
   question; size in hours.
5. Replace the ratio argument with a difference: net contacts created
   for the moved population on one definition.

## Sizing before the model is settled

Sometimes a phase must be sized before the measurement model is signed.
Then: the range is wide enough to hold both readings; the register
names the reading that would narrow it; the gate record says the sizing
is provisional and dates the re-run.

## What would change this

A migration sized on a ratio alone whose first measured period landed
within the plan's own tolerance on volume and on handle time. Record it
with its definitions; the ratio may be a valid sizing where units,
definitions and handle time were all stable across the change.

Block 5 — migration-runbook.md

<!-- Derived from [[Migrating a Book of Business]]; figures marked [estimated] are judgment, not measurement; numbers carry [M][C][E][A]. -->
# The book-migration runbook (BM)

## The eight steps, in order

| Step | Done when | Produces |
|---|---|---|
| 1 Definitions first | Every object and every sized metric has a register status (settled · mapped · open with owner) | The inventory status |
| 2 Measurement model settled | The dated block is signed by the definitions owner | The measurement model |
| 3 Baseline like for like | Recomputed on the moved population, one definition, stated window | The baseline [M] on the sending side; [A] as a prediction |
| 4 Delivered hours read | Scheduled, staffed, productive hours by cohort and tenure from the short-term WFM engine | The supply ledger for the moved population [M] |
| 5 Phase sized as a range | Hours by channel; the assumption register with carried rows labeled; scenarios as versions | The sizing [E] |
| 6 The phase gate | Steps 1–5 done; the record names what would change the sizing and who re-runs it | The phase decision, recorded (the owner decides) |
| 7 Change-control item | The phase date is in the board's log and on the collision calendar | The change record; a moved date re-opens step 5 |
| 8 Adapters, files first | Forecast out and actuals in as stamped files with a mapping and a signature; unsigned or unmapped refused and logged | The mapping file; the crossing log; the rejection log |

## The phase gate

The migration's own acceptance test for the next phase. It admits a
phase to the calendar; it is not the acceptance gate of the process
standardization lifecycle, which admits a document to the standard.
Gate record fields: phase · sizing version cited · steps 1–5 status ·
open objects and their owners · what would change the sizing · who
re-runs it · the owner's decision · date. A phase that lands without the
gate has not been decided; it has been scheduled.

## Two standing rules

- The planning function is in the resource call for every phase, so
  the capacity consequence is stated before the decision. Where that
  has not been the practice, the runbook is the instrument that makes
  it one.
- The migration schedule is a change-control item owned by the board
  that owns configuration; a phase date is the largest configuration
  change in most quarters.

## The BM row

| Column | Holds |
|---|---|
| Book | The book's ID and name |
| Sending platform/owner | Category names, never products |
| Receiving | Same |
| Object inventory status | Settled / mapped / open, by object |
| Measurement model settled (date) | The signed block's date |
| Delivered hours read (source) | The supply extract, by cohort and tenure, window, grade |
| Phase | Which phase; its gate date |
| Sized range | Hours by channel and seats, as a range, with grades |
| Assumption register | Row count; carried rows count and labeled |
| Change-control item | Log reference; the rule that a moved date re-opens sizing |
| Adapters | Files in and out; mapping version; refusals logged |

## Adapters at the boundary

Every crossing does three things: maps every field to a register entry
or rejects it; checks the signature on anything that changes a plan;
logs the crossing. File first; an interface later, only where latency
requires it. 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.

## After the phase lands

- The first measured period on the receiving side replaces every
  carried row: relabel [A] → [M] with the ledger version, or keep [A]
  and say why.
- Re-tag drivers: a cohort curve that appeared is transitional; a level
  that held is structural.
- Set the receiving channel's targets from its own first period, not
  from the sending channel's or from voice.
- Open a question row for any variance the register cannot explain.

## Moving a book onto a fresh instance

Same eight steps. The order of books is cleanest first, the book in the
middle of a servicing-platform migration last; each move a board item;
each move's rejection log is the administration backlog.

## What would change this

A migration whose phases were sized without steps 2–5 and whose first
measured periods matched the sizing within tolerance. If found, the
gate should be lighter and steps 2–5 become checks rather than
preconditions.

Usage notes

Sizing. The instruction block is about 500 words; the four reference blocks total roughly 2,800 words, within a Claude project's knowledge budget with room for the book's own inventory, register extract and supply data as additional files.

Drift. Reference blocks are derived from the Source articles, not copied. When any Source article changes materially (the runbook's steps, the register's fields, the channel-conversion page's rebaselining practice), regenerate the affected block and increment the version.

Scope. The pack sizes and records. It does not decide the migration, set product parameters, judge a partner, or build the register.

Change history

Version	Date	Change
1.0	Sep 2026	First release

See also

• Planning Week for a Workforce Function
• Wiki:Packs
• Wiki:Packs/Technology Plan — the register and the sub-plan shells (CP-WFM-016)
• Wiki:Packs/Executive Issue Register — the register through which a migration's open issues reach a leader (CP-OPS-002)