Mainframe–Cloud Workload Boundary Director

The mandate

Benefit portals, document workflows and analytics have moved to cloud services while calculation, payment instruction and member history remain on the mainframe. Incremental interfaces now duplicate validation, scheduling and recovery logic, and teams disagree about which side is authoritative when a transaction spans both. The defined problem is to set a durable workload boundary before the next migration wave adds more distributed ambiguity.

The named deliverable is a Mainframe–Cloud Workload Boundary and Transition Decision Architecture. It must map business capabilities, transaction finality, data authority, batch and event dependencies, control evidence, latency, recovery, security, economics and skills; classify workloads to retain, wrap, extract, re-engineer or retire; and provide sequenced transition gates with rollback and decommission conditions.

Four milestones govern five months: by week three, approve the capability and transaction inventory; by week nine, deliver current-state authority and failure maps; by week sixteen, complete workload disposition, economics and transition experiments; and by week twenty-two, submit the accepted architecture, migration sequence and board decision paper. Each milestone is invoiced after its review.

Acceptance belongs to the administration officer and assurance panel. They will sign only when every material pension transaction has one declared system of record, cross-platform failure and replay behaviour is specified, batch-window and peak constraints are measured, control owners agree evidence handoffs, economics include dual running and retirement, and a client team can apply the disposition method to an unstudied workload.

The client will provide mainframe inventories, job and transaction traces, interface contracts, cloud designs, control narratives, incident history, cost data, skills profiles, representative test environments and accountable operational experts. The consultant will not rewrite applications, execute migration, select suppliers, alter benefit rules or certify regulatory compliance; inaccessible code or undocumented dependencies will remain explicit decision risks.

Why this is external work

Legacy and cloud teams each describe the boundary in the vocabulary of the estate they operate and have delivery commitments attached to their preferred outcome. The programme office can track migrations but cannot independently decide transaction authority or retirement proof. External hybrid-platform experience is required to resolve the boundary without treating either wholesale exit or indefinite coexistence as the predetermined answer.

What you will own

• Map pension capabilities to programs, jobs, data stores, events, interfaces, controls, operators, recovery steps and member consequences.
• Identify authoritative state and transaction finality across calculation, adjustment, payment instruction, document, correspondence and member-history journeys.
• Trace batch, online and event dependencies through peak, late-file, replay, partial-commit, duplicate and regional-failure scenarios.
• Classify workloads for retention, encapsulation, extraction, redesign or retirement using common risk, value, economics and operability evidence.
• Model dual-running, data synchronisation, licence, platform labour, capacity, testing, rollback and decommission costs over each transition path.
• Define gates for interface stabilisation, shadow processing, reconciliation, traffic movement, source retirement and evidence archive.
• Deliver the decision architecture, workload register, transition waves, proof requirements and unresolved executive choices at final acceptance.

Candidate qualifications

• Led architecture decisions across production mainframe and cloud estates supporting pensions, banking, insurance or comparable long-lived transactions.
• Defined system-of-record and finality boundaries where batch, synchronous and event-driven processes crossed platforms.
• Separated workloads that genuinely required re-engineering from components safely retained behind stable contracts.
• Built migration economics including dual operation, specialist skills, licence, reconciliation, rollback and provable decommissioning.
• Diagnosed a cross-platform recovery or replay failure created by ambiguous ownership rather than component unavailability.
• Delivered a classification method that client architects applied independently to workloads outside the consultant’s original sample.

Non-negotiables

• Can complete both Canadian operating-centre residencies and all four milestone reviews within five months.
• Will disclose relationships with mainframe, cloud, migration-tool and systems-integration providers before examining options.
• Brings executed mainframe–cloud workload disposition; strategy decks or single-platform architecture alone are insufficient.
• Accepts client replication of the method and one authoritative owner per material transaction as acceptance conditions.

1. 49 words maximum. Describe a transaction whose system of record became ambiguous after only its customer-facing steps moved to cloud.
2. 49 words maximum. Which evidence would justify retaining a mainframe workload despite an enterprise exit target?
3. 49 words maximum. How would you prove a retired platform component is no longer required for recovery or statutory history?