ERP Implementations: The Environments You Actually Need (Without the Chaos)
One of the smartest ways to prevent delays, broken testing cycles, and go-live crises is to set up your ERP environments properly from day one. Most organizations either operate with too few (leading to collisions and rework) or too many (adding cost with no benefit).
Here’s the realistic, no-nonsense environment strategy you actually need — based on real Dynamics 365 Finance implementations but applicable to any modern ERP.
Core Environments
1. Development (DEV)
Purpose: Technical development, extension work, interface builds, and functional unit-test scenario preparation.
Who uses it:
– Technical team (primary)
– Functional consultants (limited access, mainly to validate configurations and prepare unit-test scenarios)
Reality check:
This is not for business testing. DEV is where things break — intentionally.
Common issues:
– Too many hands inside
– Users trying to run business scenarios in DEV
– No refresh cadence
Fix:
Strict access + predictable refresh from TEST. Keep DEV clean and controlled.
For a deeper look at how roles and responsibilities should be structured across environments, see Designing ERP Security Roles: A Governance Approach.
2. Test / QA (TEST)
Purpose: Unit testing, integration testing, and validating configuration builds.
Who uses it: Project team only.
Must include:
– Updated extensions
– Valid parameters
– Representative master data
– Enough transactions to test end-to-end flows
Typical issues avoided:
– Dirty data causing false defects
– Endless regression cycles
– Re-opening closed bugs due to environment drift
TEST is your project’s “real-world simulation.” Treat it accordingly.
If you’re planning your data migration stream, read ERP Data Migration: The Traps to Avoid.
3. User Acceptance Testing (UAT)
Purpose: Validate the end-to-end business processes with real users.
Who uses it: Key users, SMEs, finance, supply chain, operations.
Critical rule:
UAT is NOT for discovering requirements. It’s the final confirmation that you’re ready for go-live.
UAT collapses when:
– Data is unrealistic
– Scenarios aren’t prepared
– Users are not trained
– No alignment on pass/fail criteria
UAT quality is directly linked to scoping discipline. My post on Real-Life ERP Implementation Lessons explains why misalignment happens so often.
4. Training (TRAINING)
Purpose: Hands-on learning for end users without contaminating testing environments.
Who uses it: All users undergoing training.
Why it matters:
Training often happens while TEST, UAT, and PRE-PROD continue to evolve. A dedicated TRAINING environment prevents disruptions when other environments need:
– a refresh
– a hotfix
– a configuration update
– a code deployment
Benefits:
– Stability during long training windows
– Clean, simplified data
– Repeatable exercises
– Zero interference with testing cycles
For role-based access and training alignment, see ERP Security Roles & Governance.
5. Pre-Production (PRE-PROD)
Purpose: Dress rehearsals, mock go-lives, and final cutover validation.
Who uses it: Entire project team.
PRE-PROD is your “mini go-live.”
If PRE-PROD breaks, production will break.
Used for:
– Cutover practice
– Volume & performance validation
– Full integration tests
– Final approvals and sign-offs
Rule: PRE-PROD = Frozen. No new features. Stabilization only.
PRE-PROD is also where you validate reconciliations between subledgers and the general ledger — covered here: Ledger vs Subledger in D365 Finance.
6. Production (PROD)
Purpose: Live system.
Who uses it: Entire organization.
Key responsibilities:
– Strict access controls
– Change management discipline
– Regression testing for updates
– Monitoring and support processes
Value-Added Environments
7. GOLD (Master Configuration Environment)
The authoritative source of configuration truth.
Used for:
– Approved configurations
– Parameters
– Reference data
– Templates for new environments or rollouts
8. Standard Contoso Environment
Purpose: Compare real solution vs pure standard functionality.
Helps you:
– Validate if a requirement is standard
– Remove unnecessary customizations
– Accelerate workshops
– Challenge assumptions
This ties directly into lessons covered in Real-Life ERP Implementation Lessons.
9. Data Migration Environment
Purpose: Build and validate migration scripts without polluting project environments.
Used for:
– Mapping
– Template design
– Transformation testing
– Trial loads
– Reconciliation dry-runs
Pair this with ERP Data Migration – Traps to Avoid for a clean migration stream.
10. Performance Testing Environment (TEMPORARY)
Purpose: Validate performance under real-world volumes and concurrency.
Used for:
– Load testing
– Stress testing
– High-volume posting
– Batch sequencing
– Integration peak loads
– Tuning before go-live
This environment usually exists for 4–8 weeks.
Performance testing also supports reporting cycles — something influenced by licensing nuances discussed in D365 Finance – New Licensing Approach.
Recommended Environment Strategies
Minimum viable:
DEV / TEST / UAT / PROD
Professional setup:
DEV / TEST / UAT / TRAINING / PRE-PROD / PROD
Best-practice (D365):
DEV / TEST / UAT / PRE-PROD / PROD / GOLD / CONTOSO / DATA MIGRATION / TRAINING / PERFORMANCE TEST (temporary)
