Platform Migration as a Definitional Forcing Function
Platform migration as a definitional forcing function is the observation that a workforce-platform migration in a multi-heritage service estate cannot be executed until the objects the platform holds — gates or queues, skills, pools, activity states, intent categories — have one shared definition, and that the migration therefore converts definitional work from hygiene with no deadline into critical path with a date. The consequence is strategic rather than technical: the business case for a data-definitions program is almost always argued on cleanliness and comparability, which persuade slowly, when the strongest case available is that a migration already committed to cannot land without it. This page sets out why definitions block a migration, the object inventory that must be settled, the separation of platform-bound from practice-bound findings that an assessment written during a migration must make, and the sequencing that follows. The migration itself — discovery, design, data migration, configuration, parallel testing, cutover and stabilization — and the harmonization of roles and pay across merged workforce functions are at M&A Workforce Integration Patterns; the demand-side twin of the definitional work is at Intent Normalization Before Work Placement.
Why definitions block a migration
A workforce platform is a set of definitions with a scheduler attached. It holds a taxonomy of skills, a structure of queues or gates that work arrives into, a set of pools that agents belong to, a vocabulary of activity states that decide what counts as available and what counts as occupied, and the mapping from each of these to the routing platform's own objects. A single heritage's instance of the platform encodes that heritage's definitions. When two or more heritages are migrated onto one instance, the instance can hold one taxonomy, and the heritages arrive with several.
The collision is not abstract. Two heritages' skill taxonomies cannot both be loaded; one must be mapped onto the other or both onto a third. Two heritages' notions of what a designated team is — a routing state in one, a client-count band in another (see Designated, Shared and Dedicated: What the Words Implement) — cannot both be configured. Two heritages' activity-state conventions produce two different occupancy numbers for identical work, and the migrated instance will report one of them for everyone (see Occupancy). Each of these is a decision that the migration forces, on the migration's timetable, whether or not anyone has decided to decide it. An estate that defers the definitions program until after cutover has not deferred the decisions; it has delegated them to whoever configures the target platform, usually under time pressure and usually by adopting one heritage's configuration wholesale.
The object inventory
The objects a migration forces into shared definition are few, and each has a downstream dependency that is larger than the object.
| Object | What differs by heritage | What the migration forces | What depends on it downstream |
|---|---|---|---|
| Gates or queues | Granularity; whether client-specific gates exist; what a gate promises | One gate structure, with the promise each gate carries stated | Designation, gate expansion, the idle-cushion economics of small gates |
| Skills | Taxonomy depth; whether skills are capabilities or routing labels; proficiency levels | One skill taxonomy with a mapping from each heritage's | Cross-training and chaining design; any capability record; supply-side routing |
| Pools | Membership rules; whether pools follow the org chart or the work | Pool definitions indexed on work attributes rather than reporting lines | Fungibility across the estate; the placement engine |
| Activity states | What counts as available, occupied, productive auxiliary | One state vocabulary and one convention for signalling off-queue work | Occupancy comparability; idle-capacity measurement; variance harvesting |
| Intents | What counts as a new booking, a change, an assist, by channel and brand | One intent taxonomy at the routing layer — forced by this migration only where the routing platform moves in the same program; otherwise the adjacent program this one must be sequenced with (see below) | Demand-side routing; any placement decision 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 heritages |
The right-hand column is why the inventory is strategic, and it is also why the objects belong under master-data governance rather than platform administration.[1] Each object's definition is small; the thing it gates is a capability the estate wants for reasons that have nothing to do with the migration.
Platform-bound and practice-bound findings
An assessment of a heritage that is about to be migrated describes a system that is going away, and the assessment must say which of its findings go with it. A weakness in something the retiring platform does differently from the target — a report it cannot produce, a skill structure it cannot represent, a state it cannot record — is a migration risk: it will be resolved, or reshaped, by the migration, and investing against it on the retiring platform is spending against a system being retired. A weakness in practice, process, definitions or roles survives the migration unchanged and is real. Interpreting WFM Maturity Assessments carries the general form of this separation; the migration case is its sharpest instance because the platform difference has an expiry date, and a write-up that does not separate the two classes will recommend spending against a platform being retired while leaving the practice gaps, which persist, unaddressed.
Two programs that are one
Definitional work has a demand-side twin. Routing platforms classify arriving work by intent, and in a multi-heritage estate what counts as a given intent differs by channel and by brand. If intents are inconsistent and work lands in the wrong queue, no supply-side definition of gates, skills and pools delivers fungibility, because the work being routed is not what the queue was defined for. Intent normalization and the supply-side definitions program are the same work seen from two sides, and running them as two programs with two owners produces two taxonomies that must later be reconciled — a third definitional project. Intent Normalization Before Work Placement carries the demand side; the sequencing rule is that neither is finished until both agree.
Sequencing and the clock
M&A Workforce Integration Patterns gives the migration's phases — discovery, design, data migration, configuration, parallel testing, cutover, stabilization. The definitional gate belongs before design closes: the inventory above is the list of objects discovery must produce a shared definition for, and design — the mapping of each heritage's configuration onto the target — cannot be completed until it has. Definitional defects that survive design do not surface at cutover; they surface in stabilization, in the first forecast cycle and the first schedule run on the merged taxonomy, where they are indistinguishable from ordinary post-migration noise. Placed there, the definitions program acquires what it never has on its own — a date, a sponsor who needs it, and a consequence for slipping. Ross, Weill and Robertson's operating-model framework makes the general point that standardization and integration are choices about which processes must be identical across units and which data must be shared, made deliberately rather than inherited from whichever unit's system wins;[2] a migration is the moment that choice is made whether or not it is made deliberately.
The same program argued as the critical path of a migration already committed to, with a cutover date, is a schedule risk that leadership already owns. The second argument is the one to use.
Failure modes
- Migrating one heritage's configuration wholesale. The largest or most senior heritage's taxonomy becomes the estate's by default, and the other heritages' work is described in a vocabulary written for different work. This is distinct from the deliberate selection of a surviving system on capability grounds at M&A Workforce Integration Patterns; the failure is defaulting rather than choosing.
- Deferring definitions to after cutover. The decisions are made anyway, under time pressure, by the configuration team, and are then defended as technical constraints.
- Assessing the retiring platform as if it were staying. Investment is recommended against weaknesses the migration will remove, while practice gaps that will survive it are under-weighted.
- Orphaning a constrained segment. Where part of one heritage's workforce is subject to eligibility restrictions that bind at hiring as well as at routing — security clearance, regulatory licensing, client-mandated nationality or location rules — it cannot be absorbed into pools defined without those restrictions. Its gate, skill and pool definitions have to be answered for explicitly during design, or the segment is discovered unplaced at cutover.
- Running intent and definitions as separate programs. Two taxonomies, two owners, and a reconciliation project nobody budgeted.
Maturity Model Position
The forcing-function argument sits at the Level 2 to Level 3 boundary on the WFM Labs Maturity Model™: it is the mechanism by which a multi-heritage estate acquires the shared definitions that Level 3 automation and every level above it presuppose. In the terms of The Maturity Diagnostic and Pathways, a migration is the event that makes the Technology pillar drag the Interpersonal and Processes pillars up with it — or, mishandled, the event that locks the drag in.
See Also
- M&A Workforce Integration Patterns — the migration phases and workforce-function integration
- Intent Normalization Before Work Placement — the demand-side twin
- Designated, Shared and Dedicated: What the Words Implement — the vocabulary the migration forces into one meaning
- Interpreting WFM Maturity Assessments — separating platform from practice in assessment
- Inherited Sourcing Doctrine in Merged Service Estates — why the heritages arrived with different definitions
- WFM Data Governance and Quality — the governance framework the definitions live in
