You are here:
Compare Transactional Data Migration Approaches
Compare four ways to handle transactional data at go-live to weigh simplicity and speed against dual-system work, ongoing effort, and unified reporting.
No Migration
Draw a clean line. All new business from the go-live date is processed in Revenue Management. Existing CPQ data stays in CPQ.
The execution is simpler, there's no migration risk, and an immediate go-live is possible. However, sales reps must work in two systems for a certain period of time, the reporting is split, and renewals of CPQ-originated subscriptions require CPQ access.
This approach is best for companies with a small install base, short contract terms, or those companies that want a clean break.
Partial Migration
Prioritize migration of records with upcoming renewals, amendments, or active billing. Sequence migration in descending order of renewal date.
The most relevant data is available from the beginning, the scope is easy to manage, and there's no additional sales effort required. However, it's an ongoing migration effort until the backlog is cleared. Future-phase design changes may affect migration scripts.
This approach is best for mid-market companies with a manageable install base and phased rollout alignment.
See Partial Migration in Understand Migration Strategies.
Full Migration
Migrate all legacy transactional data, including historical records, within the go-live window.
The complete data is available from the beginning, reporting is unified immediately, and there's no parallel system in operation. However, this approach is most complex and time-consuming, involves significant migration engineering effort, and edge cases in historical data should be anticipated and tested thoroughly.
This approach is best for companies with strong data governance, clean historical records, and a strict requirement for unified reporting from the beginning.
See Full Migration in Understand Migration Strategies.
