Learning Objectives
By the end of this lesson you will be able to:
- Apply the PDM selection criteria to evaluate a migration tool for a given scenario
- Explain how software selection is documented in the MSG
- Describe the risks of tool selection that is driven by preference rather than fit
Selection Criteria in PDM
Software selection for a data migration is documented in the MSG. PDM identifies the following selection criteria:
Scale How many records, how many LDS, how many concurrent users during the migration window? A tool that performs well on 100,000 records may fail catastrophically on 100 million.
Budget Licensing, implementation, and training costs. General-purpose ETL tools can cost significantly more than scripting approaches. The budget policy (captured in the MSG) constrains the options.
Migration Strategy and Form A big-bang migration has different performance requirements than a phased migration. A parallel running scenario requires the ETL to support ongoing change capture. The migration form determines what the tool must be capable of.
Local Software Policies “We only buy Oracle products” or “all tools must be cloud-hosted” are policies that constrain the selection. These are surfaced in the MSG policy review.
Local Preferences Existing skills in the team, existing vendor relationships, tools already in use on the wider programme. These are legitimate selection factors but should not override fit.
Availability of Trained Resource A tool that requires scarce specialist skills creates a resource risk. If the project has two qualified practitioners and both leave, the programme stops.
Market Availability Is the tool actively developed and supported? A migration that runs for two years depends on the tool being maintained throughout.
Common Selection Mistakes
Preference-driven selection: Choosing a tool because the team has used it before, regardless of fit. A tool that was appropriate for a 500,000-record integration project may be entirely wrong for a 50-million-record migration.
Licence-driven selection: Choosing a tool because it is already licensed, even if it is poorly suited. The cost of the wrong tool is measured in project delay and rework - usually much more than the cost of an appropriate licence.
Supplier-driven selection: Accepting the supplier’s preferred tool without independent assessment. The supplier may have legitimate reasons for their preference (existing skills, partnership agreements), but the client should ensure the reasons align with project fit, not supplier commercial interests.
Ignoring scalability: Testing with 10% of the data volume and assuming the tool will scale. Transformation logic that runs in 2 minutes on a sample often runs in 4 hours on full volume - which may exceed the cutover window.
Documenting the Decision
The software selection decision is captured in the MSG with a brief rationale:
- The options considered (Wire Card summary)
- The selection criteria applied
- The tool selected and why
- Any risks or constraints associated with the selection
This documentation is important for governance: if the tool selection is later questioned (by a programme board, an auditor, or a new project manager who inherited the project), the rationale is on record.
Re-evaluation Triggers
The tool selection should be revisited if:
- The migration scale changes significantly (more LDS, higher volumes)
- The budget changes
- The supplier or technical team changes
- A pilot reveals that the selected tool has significant capability gaps
Re-evaluation is a governance decision, not a technical one - it requires programme board approval and a formal assessment against the updated criteria.
Key Takeaways
- Selection criteria: scale, budget, migration strategy/form, local policies, preferences, resource availability, market availability
- Common mistakes: preference-driven, licence-driven, supplier-driven, and ignoring scalability
- The decision is documented in the MSG with a rationale
- Re-evaluation is triggered by significant changes to scale, budget, team, or revealed capability gaps