Before Hypercare Ends: An ERP Customisation Handover Checklist

Before intensive go-live support ends, give each business-critical custom report or integration a business owner, a maintenance owner, a clear support scope, a repeatable check and a recovery plan. The receiving team should be able to run those checks using the handover material.

Start with one workflow that matters to daily operations. A complete handover for one report is more useful than a folder of documents that nobody has tested.

What changes when hypercare ends?

Hypercare is the period of extra attention immediately after go-live. Its end should be an agreed transition into ongoing support.

Microsoft's Dynamics 365 support guidance recommends an end date, explicit exit criteria, and documentation and training for the receiving support team. It also recommends involving people who will maintain custom code and integrations before the transition.

That guidance describes a support transition. It does not establish a universal number of weeks or a standard exclusion for custom code. Your project's support agreement determines the actual coverage.

The practical question is: can the next team maintain the specific custom workflow your business depends on?

1. Which customisation are we handing over?

Name the report, integration or approval workflow. Record the business job it performs, its input, its output and where it runs.

Use a short inventory:

• Workflow name and business purpose.
• Source system and destination.
• Schedule or event that starts it.
• Current version and location of its documentation.
• A safe sample that shows the expected result.

Include the spreadsheet or manual step that remains part of the process. A handover that stops at the ERP screen leaves the next operator to discover the rest.

2. Who decides whether the result is correct?

Assign a business owner who can explain the rule, confirm the expected output and approve changes to it. Assign a maintenance owner who investigates failures and manages software changes. Record their contact routes and backups.

These jobs can sit with your team, the implementation partner or another support provider. The useful test is whether the named people have accepted the specific responsibilities.

For a custom margin report, for example, write down which adjustments belong in the calculation and who confirms the result. Treat this as a worked example, not a claim about a particular company's reporting problem.

3. What does the support agreement cover?

Check the actual agreement for this customisation. Ask the provider to distinguish:

• Restoring agreed behaviour after a fault.
• Changing the business rule or adding a field.
• Testing compatibility with an ERP or connected-system update.
• Monitoring the scheduled job and investigating missed runs.

Record the support contact, hours, escalation path, response commitment where agreed, and the process for work outside scope.

Custom work can be included in a support service or covered separately. Resolve that question for your workflow before the intensive support period closes. A general promise of "ERP support" does not describe every maintenance task.

4. How will the next person check a change?

Create a small acceptance table with a starting condition, expected result and independent way to confirm it.

For an order import, a useful worked example includes a valid order, a repeated order ID, a missing required field and an interrupted run. Define whether each case should be accepted, rejected or held for review.

Keep the examples safe to share. Record the expected behaviour before making the next change, then run the checks again afterward. A screen that looks correct is only part of the evidence; check the destination record as well.

5. What happens when a run stops halfway?

Document how the operator detects a failed or incomplete run, what they should pause, and which owner they contact.

For the order-import example, the recovery question is concrete: which orders have already reached the destination, and how does the next run avoid duplicating them?

The recovery instructions should state how to identify completed work, what needs review, and who authorizes a retry or restoration. Rehearse that path in a safe environment. Keep credentials and private customer records in the company's approved systems.

6. Can the receiving team use the handover?

Ask the receiving maintainer to walk through one normal run and one failure case using the supplied material. Have the business owner verify the result.

Record any missing access, unclear rule, unsupported component or unresolved defect with a named owner and next review date. Confirm the transition criteria and support arrangement before closing the handover.

The result is a small maintenance record that the team can use when a report changes, an integration stops, or an ERP update arrives.

Where should you start?

Choose the custom workflow whose failure causes the clearest operational problem. Gather its current support scope, business rule, safe example and maintenance contact.

Omni Care's Software Problem Clinic helps teams describe one stuck workflow and decide whether the next step is a process change, configuration, an existing tool, a scoped software fix or a maintenance plan.

Bring one custom workflow to a software diagnostic.

Frequently asked questions

Does hypercare always end after a fixed number of weeks?

The end date and exit conditions depend on the project and agreed support arrangement. Check your own plan and confirm what ongoing support takes over.

Does ERP support include custom reports and integrations?

Coverage depends on the agreement and the specific component. Ask about fault restoration, enhancements, compatibility checks and monitoring separately.

Do we need to replace our ERP to fix a handover gap?

Start by identifying the missing rule, support scope or maintenance responsibility. That assessment determines whether the next step requires software work.

What should we bring to a diagnostic?

Bring a plain description of one workflow, who uses it, what breaks, the systems involved and the decision you need to make. Use safe examples and keep confidential records and credentials in approved systems.