Implementation, Configuration, and Customization
Implementation, Configuration, and Customization
This domain tests how you build and configure a solution in controlled environments, decide when customization is justified, and migrate data safely.
Core rules
- Prefer standard configuration over code. Customize only when a documented business requirement cannot be met by configuration or process change, and record the support and upgrade impact.
- Keep environments separated: development, test, staging or pre-production, and production. Promote changes through a release pipeline; never configure production directly.
- Use version control, peer review, coding standards, and repeatable deployment scripts.
- Run data migration as a cycle: extract, profile, cleanse, map, load, validate, and reconcile. Rehearse at least twice with production-like volumes.
- Define a configuration baseline and document every setting that differs from standard.
- Plan rollback before cutover.
Worked example
A client requests a custom field to calculate discount approval. The consultant finds a standard approval matrix supports thresholds and roles. She configures it and documents the one gap: a report field. Reasoning: the standard feature meets the control objective; a custom calculation would add upgrade risk and testing burden for little value.
Traps
- Over-customizing to avoid a process conversation.
- Configuration drift between environments.
- Skipping data profiling until load day.
- No rollback plan.