Prove the operating model before production activation
Map current systems and responsibilities, validate data, controls, integrations and evidence, then compare proposed ZoikoSuite behavior with current operation — before anything is activated.
Prove the operating model before production activation
Map current systems and responsibilities, validate data, controls, integrations and evidence, then compare proposed ZoikoSuite behaviour with current operation — before anything is activated.
Explore the adoption model →Shadow Mode does not itself authorize live actions. Activation, recovery, timelines and replacement scope require customer-specific validation, accountable approval and implementation planning. Availability and support depend on approved scope.
MIGRATION CONTROL CENTER
As of 04 Aug 2026 09:12
WORKSTREAMS — SCOPE, SOURCE, TARGET ROLE AND DISPOSITION
| Workstream | Owner | Current Source | Target Role |
|---|---|---|---|
| Supplier & payables | Priya Nair | Finance system class | ★ GOVERNED WORKSTREAM |
| Contract obligations | Aisha Rahman | Contract repository class | ★ REFERENCE / READ-ONLY |
| Policy & decision records | Maya Chen | None — new | ★ AUTHORITATIVE |
| Workforce context | Daniel Foster | Payroll system class | ★ REFERENCE / READ-ONLY |
| Tax obligations | Unassigned | Local spreadsheet ▲ STALE | Blank — unapproved |
No overall readiness percentage, go-live score, migration duration or refuse appears in this view. Scope is real, and filtering never implies that excluded scope is safe.
What is ZoikoSuite Migration & Shadow Mode?
ZoikoSuite Migration & Shadow Mode is a controlled adoption approach for mapping current systems and responsibilities, validating data, controls, integrations and evidence, and comparing proposed ZoikoSuite behaviour with current operation before production activation. Shadow Mode does not itself authorize live actions. Activation, recovery, timelines and replacement scope require customer-specific validation, accountable approval and implementation planning.
This is not a file uploader, an ETL wizard, a progress bar or a generic implementation brochure. Migration here is a governed operating transition, and every product view on this page runs on bundled synthetic fixtures with no live action available.
Seven phases, no promised duration
Each phase names what must exist before the next one opens. None carries a fixed timeline, because timing depends on your estate rather than on the method.
| PHASE | PURPOSE | PRIMARY ARTIFACT | EXIT CRITERION |
|---|---|---|---|
| 01 · Discovery & Foundation | Establish estate boundary, system owners and initial governance baseline | Estate boundary map · Responsibility register | System and geographic perimeter certified; steering group confirmed |
| 02 · Prepare | Define entity model, mappings, interfaces, validation rules | Architecture blueprint · Mapping schema · Assessment criteria | Blueprint review approved; staging plan active |
| 03 · Migrate (Transport) | Move governed data and current baseline rules | Transport log · Lineage manifest | Source, integrity and completeness validated against agreed specifications |
| 04 · Shadow Mode | Compare proposed governed behavior with current operation | Shadow execution · Comparison records · Exception log summary | Observable model behavior demonstrated for pre-agreed sample |
| 05 · Controlled Activation | Activate one functional module scope in the defined boundary perimeter | Production gate · Readiness plan · Rollout log sheet | Human authorization record logged for the agreed perimeter |
| 06 · Stabilise | Monitor and resolve initial support and operational queries | Stability metrics · Exception/dispute log · System evidence | Incident trend within criteria limits |
| 07 · Exit Documentation | Retire legacy scope only when it is proved safe and complete | Compliance discovery · Retention approval sheet · Archive plan | Decommissioning review and retention exception satisfied |
Seven phases, no promised duration
Each phase names what must exist before the next one opens. None carries a fixed timeline, because timing depends on your estate rather than on the method.
| PHASE | PURPOSE | REQUIRED EVIDENCE |
|---|---|---|
| 01 · Discover & baseline | Establish current operating truth, sources, owners and dependencies. | Source authority matrix · dependency register |
| 02 · Prepare | Define target role, mappings, interfaces, controls and access. | Architecture decision · mapping evidence · access approval |
| 03 · Migrate & reconcile | Move approved scope and prove it reconciles. | Reconciliation coverage manifest |
| 04 · Shadow Mode | Compare proposed governed behaviour with current operation. | Shadow contract · comparison records · variance dispositions |
| 05 · Controlled activation | Activate only bounded, ready scope with a defined recovery position. | Readiness gates · recovery plan · named approval |
| 06 · Stabilize | Operate under heightened support and resolve emergent issues. | Hypercare log · exception closure · handover evidence |
| 07 · Exit / decommission | Retire legacy scope only when it is genuinely safe to do so. | Consumer discovery · retention approval · decommissioning gate |
Phases can overlap by workstream. A programme may be in Shadow Mode for one process while still discovering another — the Control Center above shows exactly that.
Current truth first, target second
A target authority stays blank until accessibility validated. Coexistence is the default assumption, not the fallback.
Current truth first, target second
A target authority stays blank until it is explicitly validated. Coexistence is the default assumption, not the fallback.
| OBJECT | CURRENT SOURCE | FRESHNESS | INTENDED ZOIKOSUITE ROLE | DECISION AUTHORITY | DISPOSITION |
|---|---|---|---|---|---|
| Supplier record | Procurement class | ■ CURRENT | Governed workflow | ZoikoSuite | Phase 5 class |
| Payable / invoice | Finance system class | ■ CURRENT | Decision context | ZoikoSuite | Finance class |
| Contract record | Contract repository class | ■ DELAYED | Reference / read | Legal reviewer | Contract class |
| Policy & decision record | None — new object | ■ CURRENT | Authoritative | ZoikoSuite | ZoikoSuite class |
| Evidence manifest | None — new object | ■ CURRENT | Evidence | All | ZoikoSuite class |
| Tax obligation | Local spreadsheet | ■ STALE — REPORT OVERDUE | ■ REQUIRES VERIFICATION | Unassigned | Unapproved |
Only bounded target data is evaluated as ZoikoSuite authoritative, and only for specific objects that are undergoing cutover. Every inherited object keeps its current source and shows a blank target. When source conflict, both values, timestamps and versions are preserved with a review path — never a silent overwrite.
Five outcomes, recorded per bounded scope
The decision is made per scope, not per programme. The same organization can complement in one process and consolidate in another, and “Defer” is a legitimate recorded outcome.
Complement
Coexists with current systems, operates alongside existing process and provides governance.
Consolidate
Replaces chosen legacy system, moves workflows and consolidates functionality.
Consolidate selected processes
Specific sub-processes move while legacy retains remainder.
Replace selected scope
One defined scope is retired in full, other scopes untouched.
Defer
No change at this time, explicit rationale recorded, scheduled review date.
Five outcomes, recorded per bounded scope
This decision is made per scope, not per programme. The same organization can complement in one process and consolidate in another, and “defer” is a legitimate recorded outcome.
Complement
ZoikoSuite adds governance around a system that stays authoritative.
Consolidate
ZoikoSuite sequences work across several systems that all stay authoritative.
Consolidate-selected processes
Specific processes move, and the rest unchanged.
Replace selected scope
A bounded scope is replaced, subject to full readiness gates.
Defer
No change is made now, and the reason is recorded rather than left implicit.
Correcting data is a separate authority from moving it
A mapping can transform a value. Only the data owner can authorize a correction in the authoritative source — and migration access is temporary, scoped and expiring.
Authority separation: Migration tooling can transform values for ingestion but cannot overwrite the source record without explicit data owner authorization. Audit record created for all transformations.
Correcting data is a separate authority from moving it
A mapping can transform a value. Only the data owner can authorize a correction to the authoritative source — and migration access is temporary, scoped and expiring.
| SOURCE FIELD | TARGET FIELD | TRANSFORMATION | CORRECTION AUTHORITY | STATUS | EVIDENCE |
|---|---|---|---|---|---|
| Supplier identifier | Supplier reference | Direct | Procurement — data owner | ■ APPROVED | Mapping record |
| Payment terms | Obligation term | Normalized to day count | Procurement — data owner | ■ APPROVED | Regulatory mapping standard |
| Supplier status | Lifecycle state | Value list diffs — 6 source values, 4 target | ■ REQUIRED DATA-OWNER DECISION | ■ IN REVIEW | Proposed mapping |
| Bank account reference | Creditor reference | Direct · masked in all non-production use | Treasury — data owner | ■ APPROVED | Masking verified record |
| Legacy tracking notes | Not mapped | Exclusion from scope | All | ■ EXCLUDED — RECORDED | Exclusion rationale |
MIGRATION ACCESS — TEMPORARY BY DESIGN
State the boundary before showing any comparison
A reviewer should be able to see exactly what Shadow Mode observes, where, with what data and identity, whether writes are possible, and who owns the boundary.
State the boundary before showing any comparison
A reviewer should be able to say exactly what Shadow Mode observes, where, with what data and identity, whether writes are possible, and who owns the boundary.
- • Northstar UK Ltd - supplier and payables process
- • Supplier bank detail change action type
- • Invoice approval action type
- • Finance system class interface — read
- • Northstar GmbH and Singapore entities
- • Payroll and workforce processes
- • Tax obligations — source stale, excluded pending review
- • Any banking or payment execution path
Shadow Mode observes and compares. It does not authorize production actions. Any live execution capability sits outside this contract and requires separate controlled-activation approval. Changing the scope or the write capability invalidates the related evidence and reopens approval.
Excluded scope is not implied to be safe. It is listed because a comparison that silently omits a process would misrepresent its own coverage.
Current versus proposed, with the cause named
Diagnosis and disposition stay separate. Identifying why a difference occurred is not the same as deciding what to do about it.
Reason and proposed disposition: Current system allows single-approver release without tax screening on cross-border payments. Proposed shadow model detects cross-border vendor, applies Rule TAX-US-UK-08, and flags for review before release. Recommendation: Review difference with Tax Counsel and determine if current practice is an accepted exception or an unmonitored risk.
Current versus proposed, with the cause named
Diagnosis and disposition stay separate. Identifying why a difference occurred is not the same as deciding what to do about it.
Route and control difference. The current path allowed the requester to approve their own change with no independent verification. The proposed path would have blocked it on two separate grounds. Dependency: the contract notice clause could not be evaluated because the contract source was delayed, so this comparison is itself incomplete and says so.
A comparison record diagnoses; it does not dispose. The disposition happens in the decision model below, by a named owner with authority over that scope.
— STABILIZATION DEMAND METRIC
What was actually tested — and
what was not
Honored scope and tested scope are separate columns on purpose. The gap between them is the most useful number on the page, and is never expressed as a rounded percentage.
| Subsystem / Capability | Configured Scope | Honored Scope | Tested Scope | Gap | Observations | Status |
|---|---|---|---|---|---|---|
Payment pipeline Authorization & settlement | 28 payment pathways configured | 28 pathways verified | 26 pathways active | Δ 2 | Direct debits in batch processing run 4 excluded from active shadow test. | • HONORED 26/28 |
Ledger reconciliation | All nominal accounts | All nominal accounts | Target ledger active | Δ 0 | Full balance sheet and trial balance reconciled across both systems. | • HONORED 100% |
Historical transactions | 10-year record migration | 7 years fully verified | 3-year active archive | Δ 4 yrs | 7-year legacy tax records migrated and verified; years 8–10 in staging offline. | • PARTIAL · 7/10 YRS (STAGED) |
Communications & notifications | Email, SMS, in-app notifications | Email and SMS verified | Email live, SMS simulation | Δ SMS (sim) | SMS provider gateway mock active; production SMS gateway will run at go-live. | • HONORED 2/3 |
Contract agreements | e-Signature & custom clauses | Template scope only | None | Δ ALL (custom) | Custom legal terms deferred; standard click-wrap and signed templates approved. | • NOT TESTED |
Fraud & compliance check | Sanctions, PEP & ID verification | Full regulatory baseline | Active shadow compliance | Δ 0 | Real-time PEP and Sanctions API queries running simultaneously on parallel feed. | • HONORED 100% |
Document store | Cloud object store | Full file index | Yes | Δ 0 | Tier 0-1 documents verified and accessible. | • HONORED 100% |
Tax determination logic | Multi-jurisdiction tax engine | UK & EU VAT | None | Δ non-EU | US Sales Tax engine deferred to Phase 6; UK and EU VAT fully verified. | — |
What was actually tested — and what was not
Required scope and tested scope are separate columns on purpose. The gap between them is the most useful number on the page, and it is never expressed as an undefined percentage.
| DIMENSION | REQUIRED SCOPE | TESTED SCOPE | METHOD | COVERAGE MODE | DEFINITION |
|---|---|---|---|---|---|
| Supplier records | All active suppliers · UK entity | All active suppliers · UK entity | Count · differential integrity | FULL | Source count equals target count, matches baseline. |
| Open payables | All open payables · UK entity | All open payables · UK entity | Count · total balance | FULL | Record count and summed balance matches target ledger. |
| Historical payables | 24 months of closed payables | Sample of 500 records across 24 months | Sample · manual review | SAMPLED | Stratified sample by month and value band; variances recorded. |
| Control outcomes | All Wave 1 action types | Two action types | Control outcome comparison | SAMPLED | Observed governance results for the action sample. |
| Contract obligations | All obligations linked to Wave 1 suppliers | None | Not run | EXCLUDED | Excluded because the contract source interface is delayed. |
| Event completeness | All ingested finance events | All ingested finance events | Event completeness | FULL | Every source event has a corresponding shadow event logged. |
| Workforce data | Staff relevant to invoice | n/a | n/a | NOT APPLICABLE | Not in the approved Wave 1 scope envelope. |
| Tax determinations | Requires verification | None | Not run | DEFERRED | ★ Requires Stale sheet to be remediated before running. |
— ANOMALY AND ISSUE DECISION MODEL
Eight dispositions, each with a
named owner
An issue cannot close simply because a phase moved on. Closure requires evidence, or an approved exception with an expiry.
Remediation
Fix the underlying capability before proceeding.
Exception (time-limited)
Explicit departure with approved expiry date. Must not be left open.
Approved divergence
Known variance with documented operational justification.
Defer
Not in current run scope; deferred to parallel sequence.
Exclude scope
Removed from scope; requires justification audit.
Process workaround
Documented procedural workaround approved by governance.
Blocked on vendor
Third party dependency issue with ticket reference.
Governed tolerance
Acceptable drift within defined mathematical threshold.
Eight dispositions, each with a named owner
An issue cannot close simply because a phase moved on. Closure requires evidence, or an approved exception with an expiry.
Remediate
Fix the underlying cause before proceeding.
Accept as intended
The difference is a designed improvement; recorded as such.
Approved exception
Time-bound, with compensating control and expiry.
Defer
Moved to a later wave with a recorded reason.
Exclude scope
Removed from the wave, visibly and with rationale.
Professional review
Routed to a qualified review before disposition.
Block activation
Prevents the affected scope from activating.
Close with evidence
Resolved and evidential — the only clean closure.
| ISSUE | AFFECTED SCOPE | PRIMARY CAUSE | CONTROL IMPACT | OWNER | DUE | DISPOSITION |
|---|---|---|---|---|---|---|
| Requester able to approve own supplier change | Supplier process · UK | Authority / role difference | Segregation control absent today | Maya Chen | 18 Jul | ★ ACCEPT AS INTENDED |
| Supplier status value set mismatch | Mapping · all suppliers | Mapping / transformation | Lifecycle state maybe ambiguous | Priya Nair | 24 Jul | ▼ REMEDIATE |
| Contract source delayed through window | Contract obligations | Integration / event issue | Notice obligations unevaluated | Aisha Rahman | Overdue | ★ BLOCK ACTIVATION |
| Historical payables tested by sample only | 24 months closed payables | Expected design difference | Population not fully verified | Priya Nair | 28 Jul | ★ APPROVED EXCEPTION Expires: 28-Nov-2026 |
| Tax source stale, scope undefinable | Tax obligations | Source data issue | Cannot assess coverage | Unassigned | Overdue | ★ EXCLUDE SCOPE |
An issue cannot close only because a phase advanced, a date passed or a workaround exists. Closure requires evidence, or an approved exception carrying a compensating control and an expiry. One issue above currently blocks Wave 1 activation entirely — that is the model working, not failing.
— READINESS AND GATES DECISION
Fifteen gates, no aggregate
score
Readiness is supported by named criteria and evidence — never by a percentage, a dial or an AI recommendation. Activation is authorized by a named person against a named scope.
GATE TYPE LEGEND
Every gate is evaluated against its named criterion with attached evidence. There is no averaging across gates and no overall percentage score for readiness in this stage.
ACTIVATION DECISION
Decided by a named person in their governance role against named bounded scope, with the evidence pack signed, exceptions witnessed and recovery positions agreed. No AI engine, algorithm, score or dashboard graph automatically authorizes production switch.
Fifteen gates, no aggregate score
Readiness is supported by scoped criteria and evidence — never by a percentage, a dial or an AI recommendation. Activation is authorized by a named person against a named scope.
SIX GATE STATES
One blocked gate is enough to prevent activation of the affected scope. There is no averaging across gates and no overall readiness figure anywhere on this page.
ACTIVATION DECISION
Recorded by a named accountable person against a named bounded scope, with the evidence reviewed, the conditions stated and the recovery position agreed. No AI output, algorithm, score or dashboard grants authority to activate production scope.
— REVERSIBLE OPERATIONS · RECOVERY AND CANCELLATION
Reversibility is stated truthfully,
including when it is unknown
Five recovery mechanisms, each meaning something different. A step that cannot be directly reversed is labelled as such rather than described as safe.
Rollback
Direct restoration to the immediate prior state in an approved, verified sequence.
Restore
Reconstruct data to a dependable prior snapshot with audit integrity.
Failover
Direct execution to alternate path under an operational exception.
Re-index/reconcile
Reconcile duplicate/altered transactions against the authoritative journal.
Irreversible operation
An approved, documented step whose prior state cannot be restored directly. Strict sign-off and evidence trail required.
RECOVERY MECHANISM AUDIT · ASSESSMENT SUMMARY
LOCKED SCOPE NOTE
One reconciliation per line item: Once the shadow drift reaches the gap metric, that is calculated directly for each line item individually:
- •Post-market reconciliation — Early detection and reconciliation of the legacy system reconciliation, including voids and refunds previously unrecorded.
- •Retention obligations — Audit trail and SLA retention requirements are satisfied to the required standard.
- •Evidence audit trails — Historical evidence remains within data warehouse.
- •Supervised ledger approval — reconciliation is approved, authority with final owners runs to closure.
Reversibility is stated truthfully, including when it is unknown
Five recovery mechanisms, each meaning something different. A step that cannot be directly reversed is labelled as such rather than described as safe.
Rollback
Return software or configuration state, where technically supported.
Restore
Recover state in a given system from an approved backup or snapshot.
Fallback
Revert the runtime path to the prior environment or system.
Business reversal
Provide adjustments to ledger when legally and operationally possible.
Compensating action
An approved corrective action where direct reversal is impossible. Some steps are genuinely forward-only.
| STEP | DEPENDENCY | REVERSIBILITY | RECOVERY MECHANISM | TECHNICAL AUTHORITY | BUSINESS AUTHORITY |
|---|---|---|---|---|---|
| Enable governed workflow for scope | Readiness gates | ★ REVERSIBLE | Rollback configuration | Platform engineer | Maya Chen |
| Redirect approval routing | Step 1 | ★ REVERSIBLE | Fallback to prior route | Platform engineer | Maya Chen |
| Begin recording decision evidence | Step 2 | ▼ FORWARD-ONLY | Compensating action — records already created are retained | Platform engineer | Compliance |
| Notify affected approvers | Step 2 | ■ NOT APPLICABLE | Follow-up communication | Operations | Maya Chen |
| Retire legacy approval path | Stabilization exit | ■ REQUIRES REVIEW | Unknown until consumer discovery completes | Platform engineer | Architecture board |
STABILIZATION EXIT — EVIDENCE-BASED
LEGACY EXIT GATE
Decommissioning is the last step and the easiest to get wrong. Before any legacy scope is retired:
- •Consumer discovery — every downstream consumer of the legacy system is identified, including reports and interfaces nobody remembered
- •Retention obligations — legal, tax and audit retention requirements are satisfied by the retained records
- •Evidence continuity — historical evidence remains retrievable after retirement
- •Decommission approval — recorded by a named authority with the discovery results attached
No migration duration, cutover date, effort estimate, volume figure, success rate or replacement guarantee appears anywhere on this page. Those are outputs of your specific implementation planning, not properties of the method.
— FREQUENTLY ASKED QUESTIONS
Shadow Mode, coexistence,
readiness and recovery
Direct first sentences, then qualified detail. Every answer is present in the page source.
It is a controlled adoption approach for mapping current systems and responsibilities, validating data, controls, integrations and evidence, and comparing proposed ZoikoSuite behaviour with current operation before production activation.
Seven phases run from discovery through legacy exit, and phases can overlap by workstream. Activation, recovery, timelines and replacement scope require customer-specific validation and accountable approval. See the lifecycle
— TRUST AND PROCUREMENT
Where migration claims get verified
Every product view above is a synthetic fixture. These are the routes where the real answers live.
Architecture
What connects, and who owns it
- Platform Foundation
- Source-of-record model
- Deployment options
Governance
Controls that must hold through cutover
- Governance Platform
- Evidence and audit readiness
- Governed lifecycle
Security and privacy
- Security overview
- Data Processing Agreement PDF · new tab
- Subprocessors
- Accessibility
Shadow Mode availability
Source and implementation dependent
Shadow Mode support, observation method and scope depend on approved implementation. This page shows the contract model, not a guarantee that it is available for your estate.
Professional boundary
Migration activity does not constitute legal, tax, accounting, audit or regulatory advice. Qualified professionals remain responsible for regulated judgment, including retention and decommissioning decisions.
No outcome guarantee
No timeline, availability, integration, jurisdiction, provider, hosting, certification, service level or migration outcome is published merely because it appears in a specification. Each requires its own approved source.
ALREADY USING ZOIKOSUITE?
Operational resources, no-demo wall
Reachable without a form or a conversation.
Status text reviewed 31 July 2026.
Start from the process you would not risk breaking
The most productive first conversation is about one bounded scope: which system stays authoritative, what would have to reconcile, what evidence you would need before activation, and what your recovery position would be. Not a programme plan.
No migration timeline, effort, cost, Shadow Mode availability or replacement outcome is committed outside an approved commercial and implementation document.
— FREQUENTLY ASKED QUESTIONS
Shadow Mode, coexistence,
readiness and recovery
Direct first sentences, then qualified detail. Every answer is present in the page source.
It is a controlled adoption approach for mapping current systems and responsibilities, validating data, controls, integrations and evidence, and comparing proposed ZoikoSuite behaviour with current operation before production activation.
Seven phases run from discovery through legacy exit, and phases can overlap by workstream. Activation, recovery, timelines and replacement scope require customer-specific validation and accountable approval. See the lifecycle
Govern your global operations with confidence
Unify finance, workforce, legal, tax, compliance, and commercial operations under one governed platform.
ZoikoSuite logo — animated
embed-128-logomovement.svg + CSS + script sandbox + 1.2.01/block/v4 written for live hero footer + url “fullvector”
ZoikoSuite®
Governed Business Operations Intelligence Platform.
A Zoiko Tech platform. A Zoiko Group company.
Governance, compliance, and enterprise operations insights.
By subscribing you agree to receive ZoikoSuite insights. See the Privacy Policy. You can unsubscribe at any time.
ZoikoIcons referencing the inline straid
vector-wrap + 24 * 24 viewBox + monochrome single-path + currentColor fill + see full src-network + footer section NF134