An enterprise application services implementation changes a business process and its system of record, integrations, data, permissions and operating responsibilities. Success is not installation. Users must complete the end-to-end work, reconciled records must survive migration, connected systems must handle failure, and internal teams must be able to support and change the service after release.
Use this checklist with the enterprise application services scope guide, the enterprise application services FAQ, the application services lifecycle guide and the application services blockchain plan. Tailor depth to criticality, regulation, user reach and reversibility.
1. Confirm process outcome, scope and ownership
Map the complete service from trigger to final record and exception. Name process owner, application owner, data owners, integration owners, security approver, change lead and support lead. Baseline completion time, error, manual work, support demand and control findings. Define in-scope business units, regions, legal entities, user roles, records, reports, interfaces and historical periods, plus explicit exclusions.
Create decision rights and design principles before configuration. Identify where the organization will adopt standard product behavior and where a legal, control or differentiating requirement justifies customization. Record assumptions about volume, concurrency, localization, retention and close periods. Use ISO 21502 to choose a delivery approach appropriate to the work, while maintaining governance across iterative or predictive phases.
| Scope artifact | Acceptance question | Owner |
|---|---|---|
| Process map | Are normal, exception and reversal paths represented? | Business process owner |
| Role model | Do duties and approvals match policy? | Control and identity owners |
| Data inventory | Are authoritative sources, history and retention known? | Data owners |
| Integration catalog | Are contracts, volumes and failure owners defined? | Integration owners |
| Operating model | Can support, release and recovery be staffed? | Application owner |
2. Baseline configuration and architecture
Configure a thin end-to-end path early. Version settings, workflows, rules, templates and extensions, and promote them through controlled environments. Keep environment differences documented and minimize direct production changes. Define availability, performance, recovery and data residency requirements. Model batch windows, month-end or seasonal peaks and dependencies on identity, network, messaging, reporting and external services.
Use supported extension points and APIs rather than modifying vendor core behavior where possible. Maintain an architecture decision record for material customization. Review product roadmap, upgrade constraints, licensing and deprecation. A configuration is still code-like change: it needs peer review, test evidence, separation of duties and rollback. Keep break-glass access protected and monitored.
3. Prepare and rehearse data migration
Profile source records before mapping. Define business keys, duplicates, invalid states, reference data, ownership and disposition for history that will not move. Create transformation rules with sample examples and owner approval. Preserve source identifiers and migration batch so every target record can be traced. Protect extracts, restrict access and delete temporary copies on schedule.
Rehearse full-volume migration more than once. Measure duration, rejects, manual correction and reconciliation. Reconcile counts, control totals, balances, relationships and representative business outcomes, not just row totals. Define freeze, delta capture, late-arriving transactions, rollback and re-run idempotency. Business data owners approve reconciliation; the migration team should not approve its own result.
| Migration gate | Evidence | Stop condition |
|---|---|---|
| Mapping approved | Field rules, examples and data-owner sign-off | Unknown meaning in critical fields |
| Trial load complete | Rejects classified and target constraints verified | Unowned or silent data loss |
| Full rehearsal | Duration fits window and totals reconcile | Critical variance above tolerance |
| Cutover delta | Late changes captured exactly once | Duplicate or missing transactions |
| Post-load acceptance | Business reports and workflows agree | Irreversible control or balance failure |
4. Verify integration contracts and failure behavior
For every interface, define producer, consumer, schema, authentication, authorization, encryption, volume, ordering, duplicate behavior, timeout, retry, dead-letter handling, versioning and support owner. Test malformed messages, unavailable dependencies, delayed events and replay. Use correlation identifiers and business keys so support can follow one transaction across systems without exposing excessive personal data.
Avoid a successful HTTP response as the only acceptance signal. Verify the downstream business state and reconciliation. Establish contract tests in delivery pipelines and monitor both technical and business failure. Plan coexistence when old and new systems run together, including which one is authoritative and how conflicting updates are prevented. Document external-party maintenance and escalation windows.
5. Build security, privacy and accessibility into acceptance
Map roles to least privilege and test segregation of duties, joiners, movers, leavers, temporary access and privileged administration. Threat-model critical flows, protect secrets and audit consequential changes. The NIST SSDF provides secure development practices that apply to custom extensions and integration code. Use the OWASP ASVS to contract and test web application security requirements at an appropriate level.
Minimize personal data and set retention, export, correction and deletion behavior. Test authorization at APIs, reports, bulk export and background jobs, not only menus. For web interfaces, use WCAG 2.2 where applicable and include keyboard, focus, authentication and assistive-technology checks. Accessibility and privacy defects can block real users even when functional tests pass.
6. Run layered testing and business acceptance
Create traceability from requirements and risks to evidence. Test units and configuration, contracts, integration, migration, security, performance, recovery and end-to-end user journeys. Use production-like data shapes with protected synthetic or masked data. Define severity and release criteria in advance. Keep known limitations, workarounds and residual risks visible to the approver.
Business acceptance should involve representative roles and exception cases. Users need realistic permissions, devices, volumes and time pressure. Verify reports against authoritative totals and test a full operating cycle, including approval, reversal, close and support. Governance should inspect evidence directly; the GOV.UK agile governance principles emphasize timely decisions, the right people, direct observation and trust with verification.
7. Rehearse cutover, support and recovery
Write a minute-level cutover plan with dependencies, commands, verification, decision points, communications and named owners. Define the last responsible rollback point and data consequences of returning to the old system. Rehearse it with operations and business teams. Protect backups and prove restore in an isolated environment. A backup job success message is not recovery evidence.
Open a command channel for launch, publish support routes and prepare knowledge articles for likely issues. Monitor completion, errors, queue depth, integration lag, permissions, latency and infrastructure. Use gradual rollout or business-unit waves where states can remain consistent. During hypercare, classify issues by root cause and transfer recurring fixes into product and process backlogs.
8. Transfer service ownership and improve delivery
Handover includes architecture, configuration sources, data models, interfaces, test packs, runbooks, licenses, vendor contacts, risks, exceptions, recovery and roadmap. Internal operators should deploy, diagnose and restore while implementation specialists observe. Revoke project and supplier access, rotate shared secrets and confirm temporary data disposition.
Track service outcomes with delivery performance. DORA's current metrics cover change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate. Apply them to one application or service in context, alongside completion, quality, support and business outcomes. Use trends to improve release size, test quality and recovery rather than turning metrics into individual targets.
A go-live decision pack
Prepare one evidence index for the go-live authority. Include scope and exclusions, business acceptance, unresolved defects, security and privacy review, accessibility result, migration rehearsal and reconciliation, performance at representative peak, recovery exercise, cutover rehearsal, support staffing, training and communications. Show each criterion as met, conditionally met or unmet with an owner. Link to evidence and state when it was produced and against which version.
The decision meeting should focus on exceptions and consequences. For each open item, explain affected users and transactions, workaround, detectability, reversal, deadline and who accepts residual risk. Confirm the rollback decision owner and latest point at which rollback remains safe. Do not let elapsed schedule convert an unmet critical criterion into implied acceptance. If a release is delayed, preserve environments and data securely and update communications rather than improvising an unreviewed partial launch.
After approval, freeze only what is necessary and log emergency changes. During cutover, evidence each checkpoint and stop when a predefined condition occurs. At business verification, users complete representative tasks and data owners approve reconciliations. The go-live record becomes the starting point for hypercare and later audit, so capture actual timings, deviations and decisions instead of replacing the plan with a clean retrospective version.
Define the exit from hypercare before launch. Criteria may include stable transaction success, reconciled interfaces, no unresolved critical defect, support demand within staffed capacity and completion of the first business cycle. Transfer cases and dashboards to normal support rather than closing them in bulk. Hold a final access and data review for implementation staff, then move improvement ownership into the application's funded roadmap. Confirm the vendor escalation path and renewal owner at the same time.
Key takeaways
- Treat enterprise application implementation as process, data and operating change.
- Prefer supported configuration and extensions, with versioning and rollback.
- Rehearse full-volume migration and require business-owned reconciliation.
- Test integration failures, role boundaries, accessibility, recovery and exceptions.
- Complete the work with practiced ownership, supplier offboarding and outcome monitoring.
Frequently asked questions
Should enterprise applications use a big-bang rollout?
Only when business state cannot be divided and the organization can prove cutover and recovery. Waves reduce blast radius but create coexistence and reconciliation work. Choose from transaction dependencies, legal-entity boundaries, data consistency, user readiness and rollback, not schedule preference alone.
How much customization is too much?
Customization is excessive when its continuing value does not justify testing, upgrade, security and support cost. Require an owner, outcome, supported design, lifecycle cost and exit for each material extension. Revisit customizations when the vendor adds standard capability or the process changes.
Conclusion
An enterprise application is ready when the organization can complete and reverse real work, reconcile its records, survive dependency failure, protect users and operate change. This checklist makes those outcomes visible before cutover. It turns implementation from a configuration project into a controlled transition of a business service.