Migration & Go-Live

Migration is not Copy Tables. It is normalization, mapping and proof.

The legacy platform contains business value we must preserve, but it also contains inconsistent taxonomies and data. Migration engineering therefore starts early, with rehearsals and reconciliation before the final cutover.

Extract → Normalize → Validate
Rehearsal · Delta · Rollback
CUTOVER PATH

Migration is rehearsed before launch day

The final cutover happens close to release, but mapping, scripts and reconciliation should already have run against realistic data in rehearsals.

RECONCILIATION

Four layers to prove the migration is correct

A script completing without an error is not enough. We prove counts, values and relationships, then inspect real records as they appear to users and Admin staff.

COUNT

How many customers, orders, products, balance records and future bookings were migrated?

VALUE

Do financial totals, wallet opening balance, stock totals and other values reconcile?

RELATION

Is every order linked to the correct customer, address, delivery group and product?

SAMPLE

Do real migrated records display correctly in App, Web and Admin?

CRITICAL FUTURE COMMITMENTS

Future appointments and bookings are more dangerous than history

If we migrate order history but fail to load future commitments into the new capacity model, the new system can expose false availability and create double-booking immediately at launch.

Legacy before go-live

Tomorrow · 6–9 PM · Mario

Confirmed legacy bookings = 5 Legacy slot commitments = active
→
New capacity system

The new Checkout must start from the truth

Mario capacity = 10 Migrated committed = 5 Remaining = 5
G
Launch gate

No future legacy delivery commitment exists outside the new capacity system. The same rule applies to Delivery Slots.

MIGRATION SCOPE

What belongs in the migration plan

Every domain gets an explicit mapping, validation and appropriate reconciliation; data such as reviews or wishlist entries is migrated only when it is reliable.

Password migration

We do not assume every legacy hash uses the same algorithm.

  1. Audit the real authentication path and hash prefixes.
  2. Keep the legacy hash in a restricted migration field.
  3. On first login, verify it using an approved legacy verifier.
  4. On success, rehash into the new Kidzy format and remove the legacy hash.
  5. On failure, use the normal recovery flow.

Go / No-Go discipline

The legacy platform is not shut down just because the new interface looks good.

  • Reconciliation signed off
  • Backups + restore verified
  • Rollback window defined
  • Payment/queue/integration health checked
  • Future commitments reconciled