Environments and Release Management
ERP environments are scarce, expensive, and shared. That scarcity shapes the whole development process and is the biggest cultural difference from ordinary software work.
The standard landscape
SBX ──▶ DEV ──▶ QAS ──▶ (PREPROD) ──▶ PRD
│ │ │ │ │
Sandbox Dev Test Staging Production
| Environment | Purpose | Data | Who |
|---|---|---|---|
| SBX Sandbox | Experimentation, proof of concept, training config | Throwaway | Consultants |
| DEV | Configuration and development | Small, synthetic or masked | Consultants + developers |
| QAS/TEST | Functional and integration testing | Masked copy of production | Testers, consultants |
| UAT | Business acceptance (sometimes = QAS) | Recent masked copy | Business users |
| TRAINING | End-user training | Curated, stable, resettable | Trainers |
| PREPROD | Performance testing, cutover rehearsal, dress rehearsal | Full masked copy | Technical team |
| PRD | The real thing | Real | Everyone |
Not every project gets all of these. SaaS ERPs allocate a fixed number of sandboxes per licence tier; extras cost money. Environment scarcity is why you can’t “just spin one up” and why environment booking is a real coordination activity.
The transport / deployment mechanism
Configuration and code move between environments as packaged, versioned artefacts:
| Product | Mechanism |
|---|---|
| SAP | Transport requests (CTS/CTS+) |
| Dynamics 365 F&O | Deployable packages via LCS |
| Business Central | Extension apps (.app files) |
| NetSuite | SuiteBundles or SDF projects |
| Odoo | Modules in git + database migration scripts |
| Oracle Fusion | Configuration packages, sandboxes |
| ERPNext/Frappe | Apps in git + bench migrate fixtures |
The golden rule
Changes flow DEV → QAS → PRD. Never the reverse. Never directly into PRD.
Every exception to this becomes permanent divergence between environments. When QAS and PRD differ, your testing means nothing.
Transport discipline
1. Make the change in DEV, in a transport/package
2. Unit test in DEV
3. Release the transport
4. Import to QAS
5. Test in QAS — this is the test that counts, because it tests the transport itself
6. Approve for production
7. Import to PRD, in the same order
8. Verify in PRD
Common failures:
| Failure | Consequence |
|---|---|
| Transports imported out of order | Import errors; objects reference things that don’t exist yet |
| A change made directly in QAS | Test passes; production fails because the change isn’t in the transport |
| A change made directly in PRD | Overwritten by the next import; environments diverge permanently |
| A transport released but not imported to QAS before PRD | Untested change goes live |
| Missing dependency (a table transported without its data element) | Import error, or worse, a runtime dump |
Config that shouldn’t move (current_number on number ranges) |
Production numbering reset — invoice numbers reissued |
That last one is worth repeating: never transport the current value of a number range. Transport the definition; leave the counter alone.
Emergency changes
Sometimes production is broken and the normal path is too slow.
EMERGENCY CHANGE PROCEDURE
1. Approval from a named authority (IT manager or on-call architect)
2. Fix in DEV if at all possible
3. Fast-track through QAS with a minimal but real test
4. Import to PRD
5. Document within 24 hours: what, why, who approved, what was tested
6. Post-incident review
7. If the change was made directly in PRD: retrofit it to DEV/QAS within 48 hours
← THE STEP EVERYONE SKIPS, and how environments diverge
Track your emergency change rate. More than 5% of changes going through the emergency path means the normal process is too slow, and the fix is to improve the normal process, not to keep using the emergency one.
Refreshing environments
Non-production environments drift from production and need periodic refreshes.
System copy: PRD → QAS
1. Announce and freeze QAS (in-flight testing will be lost)
2. Export any QAS-only configuration you need to preserve
3. Copy the database
4. Post-copy activities:
- MASK all personal and sensitive data
- Reset the system ID and licences
- Delete or redirect ALL email, SMS, and print output
- Delete or disable outbound interfaces
- Reset user passwords; disable production users
- Adjust logical system names and RFC/API destinations
- Delete scheduled jobs, or repoint them
- Reset number ranges to a test range
5. Re-import preserved QAS configuration
6. Verify and release
The post-copy activity list is a safety-critical checklist. The classic disaster: a refreshed test system that still has live email configuration sends 40,000 dunning letters to real customers. This has happened at real companies, more than once.
Automate the post-copy steps. A manual checklist executed at 2am after a 6-hour copy will miss something.
Source control
Historically weak in ERP; now expected everywhere.
| Platform | Approach |
|---|---|
| SAP | abapGit — genuinely good, widely adopted. gCTS for git-based transports |
| Dynamics BC | AL source in git natively |
| Dynamics F&O | Azure DevOps repos, model-based |
| NetSuite | SDF projects in git |
| Odoo / ERPNext | Modules are just files — git works naturally |
Put everything in git, including platform-native code. Benefits: code review, branching, history, diff, and — crucially — the ability to answer “what changed and when?” during an incident.
Configuration is harder. Config lives in database tables, and most platforms don’t export it as readable text. Options: export config as files where the platform supports it (fixtures, config packages), maintain a configuration rationale document, and rely on transport logs for the audit trail.
CI/CD in ERP
Achievable, with adaptations:
Commit ──▶ Static analysis (ATC, AL linter, ESLint)
──▶ Unit tests
──▶ Build the deployable package
──▶ Deploy to QAS automatically
──▶ Run the automated regression suite (posting assertions)
──▶ Manual approval gate
──▶ Deploy to PRD in a defined window
Realistic constraints:
- Deployment windows — many organisations only deploy to PRD on defined days
- Manual approval is usually mandatory for SOX-relevant systems
- Not everything is in source control, particularly configuration
- Shared environments mean you can’t deploy per-branch
- Database changes need care at ERP data volumes
What to automate first: static analysis and the posting-assertion regression suite. Those two catch the most defects for the least effort.
Release cadence
| Cadence | Suits |
|---|---|
| Continuous | Rare in ERP; only for low-risk side-by-side extensions |
| Weekly | Mature teams with strong automated regression |
| Bi-weekly / monthly | The common sweet spot |
| Quarterly | Conservative, or large regulated organisations |
| Emergency | Always available, always tracked |
Never release during the close window. Weeks containing month-end are frozen. Publish the release calendar with the close calendar overlaid so everyone can see it.
SaaS forced upgrades
Public cloud ERPs upgrade you whether you’re ready or not:
Microsoft Dynamics 365 2 major releases/year + monthly service updates
NetSuite 2 major releases/year
SAP S/4HANA Cloud Public 4 releases/year
Salesforce 3 releases/year
Your process:
T−8 weeks Release notes published — review for impact
T−6 weeks Preview/sandbox environment available
T−4 weeks Test your customisations and integrations against the preview
T−2 weeks Fix anything broken; deploy fixes
T Production upgrade (you don't control the date)
T+1 week Verify, monitor, address issues
Reading release notes is a real, recurring job. Assign it to someone. The alternative is discovering the change in production.
Environment governance
- A booking system for environments (who has QAS this week?)
- A refresh schedule, published
- Data masking mandatory in every non-production environment
- Production access restricted, logged, and reviewed
- No developer has write access to production configuration
- A change calendar visible to everyone
- Change advisory board (CAB) for production changes
- Emergency change process, with a tracked rate
“No developer has write access to production” is a SOX requirement, not just good practice. Developers with production write access is one of the most common IT general controls findings in audits.