Moving a corporate gifting program is not a file-import task. Recipient identity, eligibility, invitation choices, open orders, budget commitments, supplier handoffs, and privacy decisions each have a different owner and clock. A safe cutover proves that each live obligation still has one accountable home, while obsolete copies and permissions have an agreed exit path. This runbook gives IT, privacy, finance, procurement, and gifting operations a shared sequence for making that proof.
Define the migration boundary before choosing a transfer method
The first artifact is a boundary statement: which program, countries, business units, date ranges, and record states move; which remain under the old operator; and which are archived but searchable by authorized staff. A program may move new invitations to a target while the old fulfillment partner finishes parcels already dispatched. That is a legitimate split if the owner and evidence path are explicit. It is not legitimate to call every record “migrated” while two systems can independently invite or ship the same recipient.
Name a business owner for recipient experience, a technical owner for extraction and mapping, a privacy/legal decision owner, a finance owner for commitments and invoices, and a fulfillment owner for physical orders. Give each a signed exit criterion. The technical team should not decide whether a consent event is sufficient. The privacy team should not silently change a courier’s shipment state. An executive sponsor can accept a documented operational delay, but cannot waive an applicable legal duty by shortening the checklist.
Create a population inventory before any export. Count recipients by program and state; count invitation, selection, order, shipment, refund, and support records separately. Record source system, unique key, last update timestamp, record owner, purpose, retention class, destination, and whether the record contains a live obligation. Decide the cutover shape with the least risky reversible path. A clean break works only when no unsettled transaction needs the old workflow. A staged cutover can route new invitations to the target while old orders wind down. A brief dual run is useful for validation but must have one system of authority for each event. Otherwise, the same edit can be accepted twice and neither system can explain the final state. Write an authority matrix with a start and end time, not the vague instruction “monitor both.”
The nearby recipient-data governance guide addresses ongoing purpose, minimization, and retention. This runbook is narrower: it owns the temporary mapping, freeze, reconciliation, and rollback decisions of the transition itself.
Map fields and meanings, not just column names
A migration mapping should record the source field, target field, data type, allowed values, purpose, transformation, null handling, owner, validation rule, and disposition if rejected. Start with stable internal IDs, recipient identity, campaign and market, eligibility, notice or choice events, fulfillment state, cost center, ledger reference, and deletion or suppression flags. Address and phone data should not move merely because a legacy export includes them. Collect or expose them at the stage that actually needs them.
A deceptively simple column called “status” may combine invitation, order, and shipping states in one platform but separate them in another. Translate business meaning, not string labels. A legacy “completed” row might mean an invitation was claimed; the target “completed” might mean physical delivery. If a mapping would erase that distinction, stop and add explicit fields or retain the source event history. Likewise, “consent” may refer to an optional marketing choice, a recipient’s acceptance of a gift, or an approved processing basis. Those are not interchangeable. Privacy counsel must identify the legal basis for each activity; the operator preserves the notice version and choice event actually presented.
| Record family | Mapping decision | Owner | Acceptance evidence |
|---|---|---|---|
| Recipient key | Keep one stable pseudonymous link; do not match on name alone. | IT and program owner | Unique-key test and sampled identity review |
| Choice and notice | Preserve event time, locale, notice version, scope, and withdrawal. | Privacy owner | Event-by-event sample against source |
| Open order | Keep line, parcel, exception, owner, and next action distinct. | Fulfillment owner | Open-order ledger reconciled at freeze |
| Commitment and invoice | Map approved amount, currency, cost center, credit, and paid state. | Finance owner | Control totals and exception sign-off |
| Deletion or suppression | Carry the prohibition and its evidence, not a resurrected profile. | Privacy and security | Blocked import and downstream deletion test |
Caption: a source-to-target decision table is useful only when every row has a named reviewer and an observable test. Do not paste real recipient data into a public template. In the working register, restrict access to the smallest authorized team and use synthetic examples for training or vendor evaluation.
Create a reject lane before importing. Reject missing keys, invalid market values, impossible state combinations, outdated notices, and duplicate fulfillment identifiers into a controlled queue. A rejected row must have a reason, owner, deadline, and decision; it must not simply disappear from the denominator. Prefer a reversible transformation log that records what changed and why. Keep raw exports protected and time-bounded, and do not copy them into email or general-purpose chat for convenience.
Freeze the right events while preserving live service
A freeze is not necessarily a total shutdown. It is a period in which authority for selected writes is fixed so the migration can produce a trustworthy snapshot. Specify the freeze start, source watermark, event types paused, event types still accepted, incident contact, and maximum tolerated delay. Invitations can be paused while delivery scans continue; a lost parcel cannot wait for the database exercise to finish. Any allowed event after the snapshot becomes a delta that must be replayed or intentionally retained in the old system.
Use a sequence that a team can execute and audit. The mapping table above describes meaning; the following sequence describes when evidence is captured.
| Stage | Action | Evidence before moving on |
|---|---|---|
| Inventory | Count live populations and assign every record family. | Signed scope and source totals |
| Freeze | Set write authority, watermark, exception route, and contact. | Timestamped authority matrix |
| Export | Extract approved fields through controlled access. | Manifest, byte hashes, export owner |
| Transform | Apply versioned mappings and reject invalid rows. | Rule version, reject ledger, control totals |
| Validate | Compare identity, state, money, rights, and live orders. | Signed test results and open defects |
| Cut over | Route only approved new events to the target. | Routing proof and rollback trigger |
| Close or reverse | Retire old access or restore prior routing. | Owner sign-off and preserved evidence |
Caption: the cutover sequence is a compact alternative to a decorative flow illustration; its acceptance column makes each handoff testable, including on a narrow screen. The sequence is operational guidance, not an assertion that any named platform exposes these stages.
Export with a manifest: filename or object key, extraction time, source query or version, record family, row count, approved owner, bytes, and cryptographic hash. The hash detects changed bytes; it does not establish that a column’s meaning was correct. Restrict key material and credentials to the normal approved workflow. Test that the team can restore the authoritative snapshot in a non-production environment before promising rollback.
For each delta after the freeze, record source event ID, event time, ingestion time, event family, target outcome, and reconciliation result. Duplicate events should be recognized by stable identity and idempotency rules, not suppressed merely because two names look alike. If the source clock and target clock disagree, keep both timestamps and a documented ordering policy. Never erase a late withdrawal because it arrived after a successful import of an earlier preference.
Protect consent, requests, and regional decisions in flight
A platform move changes who can see and act on personal data. That is a design decision as well as a transfer operation. Make a processing register for the target with purposes, field categories, authorized roles, processors, recipient countries, retention triggers, request path, and deletion evidence. The ICO’s current data-protection-by-design guidance is relevant to building these choices into a system transition rather than attaching a privacy review after launch. A security questionnaire or encryption claim alone cannot choose a lawful basis.
Do not treat “consent” as the master key for every activity or market. If a recipient withdrew an optional choice, the target must not recreate an active preference from an older snapshot. If a rights request was open at freeze, assign an owner and deadline across both systems; do not let each team assume the other will answer it. Legal and privacy specialists should decide what must be deleted, what must be retained for a defensible obligation, what may be transferred, and which notices or agreements must be updated. The article does not authorize a particular legal conclusion.
Regional overlays matter. Taiwan’s official Personal Data Protection Act text is a primary source for local notice and processing questions; teams must verify which amendments are effective for their activity. Japan’s Personal Information Protection Commission guidance addresses entrusted handling and supervision, with separate guidance on foreign-country provision. Korea’s official Personal Information Protection Act provision on overseas transfer requires a specific applicability review. A global migration workbook should therefore carry country and recipient-group overlays, not one universal checkbox.
Keep suppression records distinct from active profiles. An organization may need a minimal do-not-contact or do-not-invite marker while deleting data that is no longer required; the lawful design is jurisdiction and purpose specific. The target import should test that prohibited IDs cannot be reactivated through a nightly batch. A delayed deletion request should remain visible in the exception ledger with a responsible owner and evidence of each downstream action.
The recipient-data operations hub explains the everyday eligibility-to-deletion lifecycle. During a migration, borrow that lifecycle as the test surface: no recipient should gain a second invitation, lose a decline, or become untraceable between sponsor, platform, support, and fulfillment.
Reconcile open orders and money before moving the switch
Open orders are where a seemingly successful data import becomes a customer failure. For each order, record line item, recipient key, selection state, inventory reservation, supplier acceptance, parcel state, carrier reference if any, promised action, refund or credit state, sponsor approval, and operating owner. Assign each line to source completion, target completion, or explicit manual exception. An order that remains in the old environment can still be represented by a read-only target reference; it should not become a second fulfillment instruction.
Build two ledgers: an operational obligation ledger and a financial obligation ledger. The first answers what must happen next for the recipient. The second answers what was authorized, committed, invoiced, refunded, or credited. Their totals need not be the same at every instant, but every difference needs a reason and owner. Finance should reconcile by currency and cost center before and after cutover, and should document how tax, shipping, supplier credits, and disputes are represented. Do not silently convert currencies or net a refund against another campaign to make a total match.
When a parcel is already dispatched, its scan and delivery exceptions should remain with the authorized fulfillment operator until a tested handoff exists. If an item is selected but not purchased, the buyer may choose to fulfill under the old arrangement or cancel and reinvite under the new arrangement, subject to recipient communication and policy. If a gift is unclaimed, the team must decide whether the old invitation expires, whether a replacement is issued, and how to prevent both tokens from remaining valid. These are explicit decisions, not row-transform defaults.
Set materiality thresholds before the test, not after a discrepancy appears. For example, a zero tolerance for duplicate shipping instructions or lost withdrawal events may coexist with a small, investigated delay in an aggregated dashboard. Thresholds should reflect risk, not a convenient pass rate. Any open financial difference needs a named approver, evidence, and close date; “known issue” without containment is not an acceptance criterion.
Prepare recipient and support messages for each route: whether an existing claim link remains valid, whether action is needed, whom to contact, and which status source is authoritative.
Hypothetical case one: an employee campaign with unfinished gifts
This is an illustrative decision, not a real customer result. A multinational employer plans to switch its employee-gift operating platform while a seasonal campaign has invitations open in Taiwan, Japan, Korea, and the United States. Some recipients have chosen a gift; others have not responded. A few parcels are in carrier custody. The proposed shortcut is to export the entire recipient table on Friday and reissue every invitation on Monday.
The program owner rejects that shortcut because it creates a duplicate-choice risk and exposes addresses for people whose gifts are already on the road. The team inventories four states: not invited, invited but unclaimed, claimed but not dispatched, and dispatched. IT maps stable program IDs and choice-event IDs. Privacy/legal reviews each market’s notice, handling relationship, transfer path, and open rights requests. Fulfillment marks already dispatched parcels as source-owned until delivery or exception closure. Finance assigns existing commitments and unspent balances by cost center.
The team then chooses a staged cutover. New invitations start in the target only after the source invitation route is disabled and a test proves old links cannot mint duplicate claims. Unclaimed invitations either remain valid in the old system until an announced expiry or are revoked and replaced one-for-one; the sponsor signs the choice. Claimed orders stay where a supplier has already accepted them unless a tested order-by-order transfer is less risky. No address is copied to the target merely to keep the new dashboard visually complete.
The rehearsal finds three classes of failure. One recipient’s two emails map to the same employee ID; the team resolves identity before import. A withdrawal event arrived after the snapshot; the delta replay must suppress the target invitation. A warehouse scan came in during the freeze; the operational ledger must show it under source ownership. Each repair changes a versioned mapping or event rule, then the test is rerun. The team does not lower the threshold because it is late.
Acceptance evidence is concrete: no duplicate active invitation for a recipient/program key; all open orders assigned one owner; source and target commitment totals reconciled by currency and cost center; sampled notice and choice histories match; post-snapshot events replayed once; recipient support can locate every selected gift. If a duplicate instruction or lost withdrawal appears in production, pause new target invitations and restore the approved source route until the incident is resolved.
Hypothetical case two: a client campaign during a deletion request
This second scenario is also hypothetical. A company changes its client-gifting service while an account manager’s campaign includes high-value client gifts. One recipient requests deletion of a stored address after an earlier delivery failure. Another has a pending replacement. The target import has a recent full snapshot, but the support queue and courier exceptions are updated separately. A simple “last CSV wins” import would overwrite the deletion flag and might trigger a second shipment.
The program owner separates the two obligations. Privacy/legal determines which address copies must be removed and whether a narrowly defined record must remain for a lawful dispute or accounting reason. Support logs the request across the old platform, target, courier, and any authorized processor, with response ownership and evidence per recipient. Fulfillment decides whether the replacement should stop, return, or continue under existing instructions, and communicates the choice in language approved by the sponsor. Finance checks whether a replacement cost or credit is already committed.
IT does not import the old profile as a live recipient. It imports only the minimal suppression or reference state authorized by the privacy owner, if permitted, and keeps a controlled mapping to the case. The team assigns the pending replacement to one operator; the target gets a read-only indication until the order closes. The recipient’s request is not treated as permission to cancel an order automatically, nor is a shipping need treated as permission to retain every address copy indefinitely.
During rehearsal, a late courier “delivered” event conflicts with the support case’s “replacement pending” status. The team holds both source events, checks the carrier evidence, and asks the fulfillment owner to resolve the physical state. It does not let a timestamp alone decide the truth. Another test shows a nightly source feed would repopulate the deleted address; the feed is blocked for that key until the deletion path is verified. The exception remains open with an owner, deadline, and audit trail rather than being silently excluded.
The cutover passes only when the rights-request ledger shows the required downstream responses, the replacement has one authorized route, no duplicate parcel can be created, finance can trace the credit, and the sponsor’s support team can answer the recipient without exposing unrelated data. If a prohibited address reappears, pause the feed, isolate affected records, restore the approved suppression state, and escalate to the privacy and security owners. Do not wait for a weekly report to discover the failure.
Test with evidence that survives a rollback
Build a test pack with synthetic or approved masked records and controlled real samples where authorized. Compare identity, latest choice, invitations, orders, shipments, money, requests, and access. Test difficult combinations such as a withdrawal during a cross-border replacement.
Each test needs expected behavior, actual result, owner, severity, evidence location, and retest result. For a field mapping, inspect a record before and after transformation. For an order, follow source line through target reference and supplier instruction. For money, reconcile control totals and investigate every variance. For privacy, test the consequence of a withdrawn choice, deletion request, expired notice, and unauthorized export. For rollback, restore a snapshot in a safe environment and show that a post-freeze event will not be lost or duplicated.
Use explicit go/no-go checks:
-
Every in-scope record family has a source count, target count, reject count, and signed disposition.
-
No recipient/program key has two active invitations or fulfillment instructions.
-
The open-order ledger assigns one next-action owner per line and parcel.
-
Finance reconciles commitments, credits, paid invoices, and currency treatment.
-
Privacy signs notice, choice, rights, retention, access, and regional transfer decisions.
-
Security confirms controlled export, import, logs, role tests, and reversible access.
-
Support can answer a real-world exception from one authoritative status route.
-
The rollback test has a trigger, operator, restored routing proof, and communication owner.
-
All high-severity defects are closed; lower-severity exceptions have accepted containment and deadlines.
Do not keep a dual run indefinitely to avoid a decision. Define how long comparison continues, who can declare stability, and what evidence permits old write access to end. Retain only records required by a documented purpose and schedule; revoke credentials, automation jobs, shared exports, and support views when they are no longer authorized. If an old vendor retains data under a contract or legal requirement, record the precise exception and review date rather than marking the environment “deleted.”
What if a supplier or recipient event arrives after the final snapshot?
Record its original event ID, source time, receipt time, owner, and business state. Replay or retain it under the approved authority matrix, then rerun the affected reconciliation. If the event conflicts with a rights request or a physical delivery state, hold the affected record for the privacy or fulfillment owner; do not let an import script pick the legal or operational answer. The exception closes only when both systems show the approved outcome and its evidence.
Conclusion: make the handoff auditable
The durable output of a migration is a signed map of meaning and responsibility: every active invitation and order has one owner, every restriction survives, money reconciles, and rollback is rehearsed. The handoff should preserve the source snapshot, rule versions, reject ledger, open defects, named decisions, and a tested way back. Only then does a new interface make the program simpler rather than merely moving risk out of view. Legal, privacy, tax, payroll, and accounting decisions remain with the organization and its advisers.
For a gifting execution layer, Giftpack is one candidate to assess against the current operating model and other proposed targets. Apply the same evidence questions to each: required recipient fields, invitation and choice control, open-order ownership, reconciliation evidence, regional access, deletion terms, and support. Test with synthetic records and confirm the current product and contract; neither an automatic migration nor a particular integration is implied.