Pilot to Production data migration
Useful for
Introduction
Pilot data should not accidentally become Production data. The transition needs an explicit decision.
During Pilot, the company is still learning. The data model may change. Test records may mix with real records. Some users may understand the environment as temporary, while others may start relying on it. That makes the move to Production a data governance decision as much as a technical one.
The migration decision
There are three broad options:
- Delete Pilot data and start Production cleanly.
- Migrate selected data after review and cleanup.
- Treat Pilot data as Production data from a defined date.
Each option has consequences. Deleting data is clean but may frustrate users. Migrating selected data requires mapping, testing and agreement. Treating Pilot data as Production data may be convenient, but only if the Pilot environment already met the right governance standard.
Detailed decision considerations
- Whether Pilot data becomes Production data.
- Customer and user agreement if data is retained.
- Migration rehearsal.
- Data cleanup.
- Audit of what was moved.
- Handling users who want deletion before Production.
- Backups before migration.
- Whether test data exists in the same environment.
- Whether user identifiers change.
- Who approves the migration.
Practical migration controls
Before migration, take a backup. Rehearse the migration in a test environment. Record what moved and what was deliberately left behind. Check user access afterwards. Confirm that audit logs, retention rules and deletion processes still make sense.
If users were told that Pilot data was temporary, get explicit agreement before retaining it. If the company cannot make that agreement clear, start Production with a clean dataset.
How this evolves as the company grows
- At Pilot, tell users whether data is temporary, retained, migrated or may be deleted.
- Before Production, decide whether Pilot data moves forward, is cleaned, is archived or is deliberately avoided.
- At Production, migration needs evidence: backup, rehearsal, validation, rollback or roll-forward and GDPR re-application where relevant.
- As the company scales, migration decisions become part of change control, customer communication and data-retention governance.
What an agent should look for
- Is Pilot data temporary or moving forward?
- Has migration been rehearsed?
- Are deletion requests re-applied after restore or migration?
What good looks like
The company can explain the decision, show the evidence behind it and identify the next point where the control needs to mature.
How Brokenhouse helps
Turn this into a practical plan.
I help technology teams turn this guidance into decisions, implementation plans, governance evidence and production-ready operating models.
Talk through your situationNext guidance
Related decisions to work through
Agent-led consultancy should amplify judgement
Agents should not replace expert judgement. They should help capture, structure, challenge, and reuse it.
Azure Dev Platform Modernisation
Describe the organisation, product, team shape, delivery model, and operating constraints.
Agentic software delivery governance
Agents used by the delivery team need a different governance model from AI models embedded in the product. Delivery agents may not be part of the customer-facing service, but they can still create risk because they may read code, write code, inspect logs, summarise documents, generate infrastructure changes or draft customer-facing material.