Checklist for Handing Over CRM and ERP Customisations to Managed Services

Preparing for the handover of CRM and ERP customisations

Handing over CRM and ERP customisations to a managed services partner requires preparation that supports operational continuity.

• Identify and document all custom modules, API endpoints and scheduled tasks.
• Ensure clear authorisations and replace shared accounts with individual service accounts using MFA.
• Plan a phased transition with a discovery phase to address missing knowledge.
• Protect the stabilisation period from new functional changes to establish a reliable baseline.

Why structured preparation matters for handing over CRM and ERP customisations

The handover of CRM- and ERP-related customisations is not an administrative change of contact person. The new service provider assumes responsibility for applications that are often involved in daily processes, while knowledge about exceptions, dependencies and actual use may be spread across employees, outdated documentation and previous suppliers. Structured preparation makes clear what is known, what still needs to be investigated and when support can begin predictably.

The state of the existing documentation determines the form of onboarding. When a usable minimum information base is available, it can serve as the starting point for the handover. If that base is missing, a phased transition in which the service provider first builds knowledge in a targeted way is more appropriate. Available information is then supplemented and validated before standard response commitments fully take effect. This clarifies which investigation is still part of the transition, rather than allowing unknown elements to emerge only during an incident.

For organisations with limited internal IT capacity, this does not mean every detail must be fully documented in advance. However, a clear distinction is needed between known components, assumptions to be validated and open investigations. This keeps business operations at the forefront: processes for which downtime or unexpected behaviour has direct consequences receive attention first. Less urgent knowledge can be added in a controlled manner during the transition.

Changes during the handover also require an explicit decision. Introducing new requirements or refactoring at the same time as establishing the baseline obscures the starting situation. In the event of an outage, it is then unclear whether the cause lies in existing behaviour, a recent change or insufficient handover knowledge. A temporary feature freeze during the stabilisation period keeps the baseline usable; desired changes can then be addressed from a better-understood service foundation.

Risks of missed checks when handing over custom software

Missed checks when handing over custom software around CRM and ERP systems often become visible only when a dependent process fails. A common problem is the informal transfer of access credentials through personal or generic accounts. As soon as an administrative account is revoked or an employee leaves, linked API keys can unexpectedly stop working. As a result, automated order exports or other critical processes can come to a halt, while the new service provider must determine without current information how the integrations function in production.

This is not merely a security issue. Uncertainty about access rights and accounts linked to automation can quickly turn a routine administrative action into time-consuming investigation. Reverse-engineering in a live environment under time pressure then increases the likelihood that business processes remain interrupted longer than necessary.

A broad, shared administrative login may appear to provide a quick start, but it introduces audit and security risks. Separate VPN connections, traceable service accounts, MFA and clearly defined permissions make dependencies visible and provide onboarding with a verifiable foundation.

Essential verifications for a secure handover

A secure handover starts with a review of access rights and documentation. Authorisations must align with the intended service role and be explicitly documented so that it is clear who may perform which actions. This keeps critical systems visible and limits unauthorised changes during onboarding.

Also verify whether the documentation covers more than the core functionality. Exception rules and operational behaviour in practice are needed to determine what counts as normal behaviour and which deviations require attention. Without that context, incident analysis takes unnecessarily long.

Formal Service Acceptance Criteria and an Early Life Support period then provide a framework for determining when a component can be handed over. The previously agreed stabilisation period supports that assessment because the behaviour of the existing environment does not change at the same time. This allows systems, process agreements and available signals to be validated before regular service management is scaled up.

Checklist for handing over CRM and ERP customisations

Use this checklist as a practical implementation of the Service Acceptance Criteria and the Early Life Support period. It helps you verify whether the access setup for CRM and ERP customisations can be handed over to a managed services partner without unnecessarily broad or unclear permissions:

• Specify the authorisations required for each environment and service task. Distinguish between access that is strictly required to manage customisations and access that falls outside the agreed scope. This prevents the handover from resulting in broader access than is operationally necessary.
• Identify and replace shared administrative accounts with individual service accounts. Map where shared credentials are still used and determine which individual accounts will replace them. Document who is responsible for issuing and revoking these accounts.
• Verify that Multi-Factor Authentication (MFA) is enabled for all administrative accounts. Assess not only whether accounts exist, but also whether MFA is correctly configured and usable for the intended administrative actions. This prevents dependency on outdated access methods.
• Explicitly separate environments and permissions. Document which service accounts are active in each environment and which permissions are associated with them. This makes service management verifiable and limits the risk of unauthorised access or audit issues.

Common mistakes when handing over custom software

The most recognisable handover mistake is not a missing file, but the assumption that all components can change service providers without issues on one fixed date. The mistakes below show why a transition also requires validation in practice.

• Handing everything over at once without a shadow phase or monitoring validation. In a so-called Big Bang Handover, all custom components move to the new service provider on a single formal date. If no shadow phase takes place and monitoring has not been validated in advance, that provider may immediately face acute incidents in code whose behaviour during use is still unknown. Incidents then immediately compete with getting to know the environment, putting recovery and knowledge-building under pressure at the same time.
• Treating the formal handover date as proof that service management is ready. A date can transfer responsibilities administratively, but it says nothing about whether the runtime situation is known. Therefore, structure the transition in stages: first observe and validate information, then assess whether the available signals are usable, and only then scale up regular incident handling.
• Allowing urgent reports to determine what turns out to be in scope. When the first incidents form the actual inventory, the scope only becomes visible afterwards. A shadow phase provides room to check relevant signals and known custom components before they reach an escalation. The organisation’s continuity then depends less on chance during the first week of service management.

Applying the checklist in your organisation

Apply the checklist as an inventory that goes beyond the visible CRM and ERP screens. A practical approach is to have the inventory for each business process supplemented by the employee who knows that process. For a data exchange process, this means identifying not only the screen or main module, but also everything that forwards, transforms or executes the process in the background at a scheduled time. This creates an overview that reflects actual use rather than only what users see every day.

This prevents onboarding from being limited to the central components of CRM and ERP. Custom microservices, transformation scripts and scheduled exports may otherwise remain unseen until a peripheral process fails. A small component between source and destination can determine whether data arrives completely or on time.

Make the inventory concrete by linking each identified component to the process in which it operates. For example, note whether the component transforms data, runs an export periodically or operates as an independent custom microservice between systems. The aim is not to elaborate technical details that are unavailable, but to make visible which components require further investigation.

With limited internal capacity, the organisation can build this list in short rounds. Start with the main processes and then ask specifically about the steps before, between and after the visible CRM or ERP action. In this way, the checklist serves as a tool for finding gaps, while outstanding components can be investigated systematically during the transition.

Frequently asked questions about handing over custom software

For teams with limited internal IT capacity, the most common question is not whether documentation is desirable, but when the transition can responsibly begin.

• Must all CRM and ERP documentation be complete before the handover starts?
  Not necessarily. Waiting until an overloaded internal team has fully described every integration can delay the transition for months. The available knowledge can serve as a basis, provided it is clear which components still need to be investigated and validated.
• Does a discovery phase mean support is immediately fully active?
  No. During discovery, responsibilities, open investigations and the conditions for scaling up are explicitly defined. This allows the organisation and service provider to distinguish between work that belongs to the transition and work that will later be handled as regular service management.
• What is the downside of waiting for a perfect internal inventory?
  An already overloaded team first receives a substantial documentation task before external support can begin. This means risks surrounding existing integrations and service management remain unresolved for longer. A phased approach makes missing knowledge visible and manageable without presenting it as fully resolved.

Key considerations for a successful handover

The transition becomes manageable when preparation is not treated as an all-or-nothing dossier, but as a series of explicit decisions about what must first be established, secured and validated. For CRM- and ERP-related customisations, the following considerations can structure those choices.

• Link the start to a defined use case and benchmark. A handover gains direction when it is clear in advance which use or process serves as the starting point and against what the first phase will be assessed. This makes expectations about the transition concrete without assuming that all components already have the same level of maturity.
• Treat integration and hardening as separate preparation for rollout. CRM and ERP customisations rarely operate independently of the environment in which they function. By giving integration and hardening attention in advance, the phased rollout remains linked to the conditions the customisations require.
• Make the financial and operational impact of uncertainty visible. Unknown components do not only lead to technical questions; they can also cause additional investigation during service management and delays when a process already requires attention. By identifying open points in advance, the organisation and partner can determine which investigation is part of the transition and which support will only be scaled up later.
• Ensure the transition ends at a concrete boundary. A phased rollout is manageable only when it is clear for each phase which customisation or integration falls within it. This boundary prevents investigation costs and operational delays from shifting to the moment when a dependent process is already under pressure.