--- title: "IFS Cloud Handover to Support: What the Package Must Hold" date: 2026-10-12 description: "IFS Cloud handover to support after go-live: specifications, scope documentation, environments, integrations and a recorded handover meeting." author: "Dariusz Myśliwiec" intro_image: "https://ifs-erp.consulting/images/articles/ifs-cloud-handover-to-support-en-1d4e757b.webp" fulltext_image: "https://ifs-erp.consulting/images/articles/ifs-cloud-handover-to-support-en-1d4e757b.webp" categories: - name: "How IFS Cloud ERP Transforms Business Operations Supply Chain AI and Legacy System Migration" url: "https://ifs-erp.consulting/ifs-cloud.md" tags: - name: "Go-Live" url: "https://ifs-erp.consulting/tags/go-live.md" - name: "IFS implementation" url: "https://ifs-erp.consulting/tags/ifs-implementation.md" - name: "IFS Cloud Implementation" url: "https://ifs-erp.consulting/tags/ifs-cloud-implementation.md" - name: "Risk" url: "https://ifs-erp.consulting/tags/risk.md" - name: "Delivery Phase" url: "https://ifs-erp.consulting/tags/delivery-phase.md" --- # IFS Cloud Handover to Support: What the Package Must Hold ![IFS Cloud Handover to Support: What the Package Must Hold](https://ifs-erp.consulting/images/articles/ifs-cloud-handover-to-support-en-1d4e757b.webp) Independent IFS Cloud practice · Go-Live ## IFS Cloud handover to support: what the package must hold, and when to hand it over **Key takeaways** - A handover to support is a package of five parts: functional and test specifications for every change, a description of the delivered solution, a register of integrations and extensions, environment and delivery details, and a recorded meeting with the receiving team. - Hand over after go-live, and hand over in parts when only one site or some modules are live. The meeting itself may happen earlier once the other prerequisites are met. - Without specifications, support cannot tell whether a reported fault is a defect or a request that was never in scope, and cannot test a fix. - Hypercare and handover are two different things: hypercare is a time-boxed stabilisation period, handover is the transfer of documented knowledge to whoever runs the system afterwards. - The project closes with the risk register and issues log closed, residual items listed with an owner, and a support plan in place. An IFS Cloud handover to support is the documented transfer of everything a support team needs to resolve an incident on a live system: what was built, how it was tested, what it connects to and where it runs. It is complete when the receiving team can answer a user's question without calling the project team. This article lists the contents of the package, the preconditions, the handover meeting and the gaps that cause trouble later. It applies to a partner support organisation, an in-house team or any other receiver, because the content of the package does not depend on who receives it. ## 1.Why does a handover to support go wrong? A handover goes wrong when nobody can say what was built and what was agreed. Check four gaps before any handover: missing functional or test specifications, specifications that are not the latest version, a handover that is never scheduled, and basic data left unreviewed after go-live. Missing specifications weigh most, because without them the agreed scope cannot be established and a reported fault cannot be judged as valid or not. Missing test specifications add a second cost: after a fix, nobody knows what to re-test. A skipped handover also leaves the receiving team reconstructing environments and customisations from scratch. Whoever receives the system inherits the same cost, whether that is a partner, an internal team or a new supplier. ## 2.What should the handover package contain? The package has five parts. The first four are a recommended structure: specifications for the delivered changes, a scope description of the whole solution, a handover document, and a handover meeting. The table splits the handover document into the registers a support team uses daily. The whole table, including the "evidence" column, is a practical suggestion, not an IFS requirement. | Area | What to hand over | Who receives it | Evidence to ask for | | --- | --- | --- | --- | | Specifications and tests | Functional and test specification for each configuration, report, integration and modification, in the latest version | Support lead | Index of specifications with version and date, each linked to a test case | | Solution description | A document or model that shows the whole delivered solution and the agreed scope, reachable by a single address | Support lead and functional consultants | A link that opens for the receiving team, with their access confirmed | | Integrations and extensions | List of third-party integrations, extensions and localisations, with owner and purpose | Technical support | One row per item with a contact on the other side of each interface | | Environments and deliveries | Which environments exist and what each is for, the delivery schedule agreed with the customer, the state of basic data | Support lead and customer IT | Environment list with owners; confirmation that master data was reviewed after go-live | | Contacts and reporting rules | Project contacts, customer information, how incidents are raised, and the handover checklist | Service desk | Checklist with each line signed by the giver and the receiver | Two registers from the package have ready-made frames on the product site: the [Interface Register Template (IDK-13)](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/13-interface-register) for the list of integrations and the [CRIM Log Template (IDK-10)](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/10-crim-log) for configurations, reports, integrations and modifications with their handover checks. A handover document should hold customer information, project contacts, a checklist for the handover, a list of third-party integrations and a list of extensions and localisations. For changes made to standard behaviour, see [the guide to IFS Cloud tailoring](https://ifs-erp.consulting/ifs-cloud/the-ultimate-guide-to-ifs-cloud-tailoring), because each tailoring decision should reappear in the specification index. ## 3.When should the handover to support happen? Plan the handover for after the customer is live, and split it when one site, one country or some modules go live first. Before go-live there is rarely enough real data to run realistic scenarios, so a handover made that early rests on untested assumptions. The handover meeting itself can run before go-live when all other prerequisites are met. This is a practical suggestion, not an IFS rule. Two further conditions are worth agreeing before the handover. First, record the customer's acceptance of the solution, kept apart from contractual project approval. Second, write all documentation in one language that the receiving team reads. Acceptance evidence comes from testing, so the handover depends on the work described in [UAT in IFS Cloud](https://ifs-erp.consulting/ifs-cloud/uat-ifs-cloud) and [IFS Cloud testing](https://ifs-erp.consulting/ifs-cloud/ifs-testing). If a tracker was kept, it belongs in the package; a ready-made structure is described in [the UAT test tracker template](https://ifs-erp.consulting/ifs-cloud/uat-test-tracker-template-ifs-cloud). ## 4.Who attends the handover meeting, and what is covered? The handover meeting is a short call between the project manager, selected project team members and selected customer and support staff, and it should be recorded and stored so that new team members can watch it later. Every implementation meets its own difficulties in core areas or in specific customisations, and knowing about them is necessary for support. A practical suggestion for the agenda, not an IFS standard: 1. **Walk through the solution description** using the real process names of the customer. 2. **Open issues and workarounds:** each with owner, age and the agreed next step. 3. **Fragile areas:** customisations, interfaces and reports that needed several attempts to pass testing. 4. **Environments and delivery schedule:** who requests refreshes and who approves a delivery. 5. **How a fault is reported:** channel, required information, and who in the customer organisation raises it. Before go-live, have a representative of the support organisation meet the customer support team to make sure fault reporting and issue resolution procedures are understood. The role that answers process questions on the customer side is described in [the tasks of an SCM product owner](https://ifs-erp.consulting/ifs-cloud/ifs-cloud-scm-product-owner-tasks). ## 5.Which gaps cause problems after the handover, and how are they avoided? Four gaps cause the problems after a handover, and each has a countermeasure that can be checked before the meeting. - **Specifications missing:** require an index listing every delivered change with a specification and a test case. A change without both is a handover blocker. - **Outdated versions:** store specifications in one location with version and date, and retire the copies in e-mail. - **Handover not executed:** put the meeting and the checklist on the project plan as a task with an owner and a date, funded in time and budget. - **Basic data not adjusted after go-live:** assign a data owner to review master data in the first weeks. The approach to loading and checking data is in [IFS DMM step by step](https://ifs-erp.consulting/ifs-cloud/ifs-dmm-step-by-step). Agree before go-live that time and budget exist for the handover. That is a planning point for the steering committee: a handover squeezed into the last days before the team is released is a handover that is not executed. Fill in the extensions and localisations list during the build, because it is hard to reconstruct at the end. ## 6.How does hypercare relate to the handover? Hypercare is a stabilisation period around go-live, while handover is the transfer of documented knowledge to the team that runs the system afterwards. An IFS community FAQ on keeping IFS informed about customer projects describes a Hypercare programme that generally lasts four weeks, two before and two after go-live, and can extend if go-live is not yet completed successfully ([IFS community thread](https://community.ifs.com/upgrades-updates-81/help-us-help-you-keep-ifs-informed-about-customer-projects-62866)). The same thread asks partners and customers to keep project information current in the IFS Service Centre, including the go-live date and the project status. That programme belongs to the IFS side. A hypercare period agreed in a partner contract, or a go-live support team on the customer's site, is a separate arrangement with its own length and scope. Check both in writing, because the handover meeting is often scheduled inside one of these windows. Go-live support is typically focused issue resolution by the application consultants together with the customer core team and expert users until the solution stabilises, after which issue management moves to the support organisation. After hypercare, the receiving team deals with updates as a routine, not an event. How service updates and release updates differ is covered in [service update vs release update](https://ifs-erp.consulting/ifs-cloud/ifs-cloud-service-update-vs-release-update), and preparation in [IFS Cloud upgrade readiness](https://ifs-erp.consulting/ifs-cloud/ifs-cloud-upgrade-readiness). ## 7.How does the project close after the handover? Close the project only when the issues log, risk register and project plan are updated and closed, and a closure document records the residual open issues and the actions needed to resolve them. Have the steering group agree that document. Agree a support plan before the go-live decision, complete the handover to the support organisation, and run a project evaluation to record lessons learned. Residual items need a destination: each one either becomes a ticket in the support queue, a backlog entry for a later phase, or an accepted risk with a named owner. For the full gate sequence, see [the IFS Cloud ERP implementation guide](https://ifs-erp.consulting/ifs-cloud/ifs-cloud-erp-implementation-guide). For the gap between handover and user adoption, see [the finish line as a risk handover](https://ifs-erp.consulting/ifs-cloud/ifs-cloud-finish-line-a-risk-handover), and for review rhythm after closure, [governance cadence](https://ifs-erp.consulting/data-governance/governance-cadence). A short piece from the author's other site covers [what is lost when the person who knew the exceptions leaves](https://www.ifs-erp.com/en/blog/knowledge-loss-employee-departure-ifs-cloud). For an outside check of the package before the meeting, see [services for IFS Cloud](https://ifs-erp.consulting/offer/services-for-ifs-cloud). ## 8.Frequently asked questions What should a handover to IFS support contain? A handover to IFS support should contain functional and test specifications for every delivered change, a description of the whole solution, a register of integrations, extensions and localisations, environment and delivery details, project contacts and a recorded handover meeting. The package is complete when the receiving team can reproduce what was agreed and test a fix. When should the handover to support happen? The handover to support happens after the customer is live, because only live data gives realistic scenarios. The handover meeting can run earlier when all other prerequisites are met, and a part handover is possible when one site or some modules are live. Who attends the handover meeting? The project manager, selected project team members and selected customer or support staff attend the handover meeting. It is kept short, recorded and stored, so that people who join the support team later can review the explanation of fragile areas and customisations. What is the difference between hypercare and handover? Hypercare is a time-boxed stabilisation period around go-live, while handover is the transfer of documentation and knowledge to the team that supports the system afterwards. The IFS Hypercare programme described in the community generally runs four weeks, two before and two after go-live, and is separate from any hypercare agreed with a partner. Why do customisations need functional and test specifications? A functional specification establishes the scope agreed with the customer, so support can judge whether a reported behaviour is a defect. A test specification shows what to re-test after a fix. Without them, onboarding the solution and delivering support both slow down. Can one site or module be handed over before the rest? Yes, a part handover is possible when one site, one country or only some modules are live. The package then covers the live scope, and the register of open items states which areas are still in the project. ## 9.About the author **Dariusz Myśliwiec**: 18 years hands-on with IFS, today on IFS Cloud. IFS Certified Associate Consultant. PRINCE2® 7. Based in Kraków, delivering remotely across Europe and globally through an independent practice. You talk to the consultant who does the work, not a sales layer. IFS is a registered trademark of IFS AB; this practice is not affiliated with IFS AB. ## Check the package before the handover meeting Send the specification index, integration list and environment list. They are reviewed against the five parts above, and missing items are listed with a suggested owner. [Contact for a handover completeness review](https://ifs-erp.consulting/contact)