Evaluate the proposed delivery team against your actual migration and operating-model problems, then contract for deliverables and acceptance. Our recommendation is to treat software capability and implementation capability as related but separate evaluations.
Ask prospective partners to explain how they would handle:
- Conflicting risk taxonomies.
- Control consolidation without losing local accountability.
- Historical evidence that the standard importer cannot preserve.
- A failed integration during a reporting deadline.
- Different decision rights for management and audit.
- Handover to your intended administrators.
Request references involving comparable workflows and migrations. Establish which named people will perform discovery, architecture, data work and testing—not only who attends the sales meeting.
A proposed statement of work should include:
| Contract component | Detail to resolve |
|---|---|
| Scope | Workflows, entities, record populations, integrations and exclusions |
| Buyer dependencies | Decisions, data quality, access, testing and availability |
| Deliverables | Designs, mappings, configuration, tests, documentation and training |
| Acceptance | Observable scenarios, reconciliation criteria and defect handling |
| Change control | Approval authority, pricing and effect on schedule |
| Handover | Runbooks, configuration inventory, support model and administrator demonstration |
Have procurement and counsel align the services agreement, software order and acceptance provisions. Do not leave a critical migration obligation between suppliers, with each assuming the other owns it.
Ask specifically who remains accountable when a configured workflow passes a demonstration but fails the buyer’s agreed acceptance scenario.