---
title: "Handover to Support Template (IDK-22)"
date: 2026-09-21
description: "Ready-to-use template IDK-22: Handover to Support for IFS Cloud implementation projects, aligned with the IFS implementation methodology."
author: "Dariusz Mysliwiec"
categories:
  - name: "Implementation docs kit"
    url: "https://www.ifs-erp.com/implementation-docs-kit.md"
---

# Handover to Support Template (IDK-22)

Template IDK-22, version 1.0. Phase: Go Live.

 ## How to use this template

 
- The project manager starts the handover and the project budget pays for it. Plan it as a project task with a date, not as something that happens when people have time.
- Prerequisites: the customer is live (a partial handover per site or module is possible), the solution is accepted, and the documentation is in English.
- Write for a support consultant who has never met this customer. If that person cannot find a specification or reproduce a test from this document, the handover is not finished.
- Rows marked `Example:` show the expected level of detail. Delete them from your working copy.
- Close with a recorded handover meeting between the project team and support (section 12). Without the meeting the handover has not happened.

 | Field | Value |
| --- | --- |
| Template ID | IDK-22 |
| Phase | Go Live |
| Owner | Supplier project manager |
| Approver | Support manager and customer project manager |
| Qualification gate | Go Live Complete |
| Version | 1.0 |

 ## Contents

 
- [Document control](#document-control)
- [1. Customer information](#1-customer-information)
- [2. Project contacts](#2-project-contacts)
- [3. Handover checklist](#3-handover-checklist)
- [4. Solution overview](#4-solution-overview)
- [5. Environments](#5-environments)
- [6. CRIM objects handed over](#6-crim-objects-handed-over)
- [7. Third-party integrations](#7-third-party-integrations)
- [8. Extensions and localisations](#8-extensions-and-localisations)
- [9. Delivery schedule and readiness](#9-delivery-schedule-and-readiness)
- [10. Basic data to adjust after go-live](#10-basic-data-to-adjust-after-go-live)
- [11. Known issues and workarounds](#11-known-issues-and-workarounds)
- [12. Handover meeting record](#12-handover-meeting-record)
- [Approval](#approval)

 ## Document control

 | Field | Value |
| --- | --- |
| Project | [Project name] |
| Customer | [Legal entity] |
| Handover scope | [Full / Partial: sites, modules] |
| Document owner | [Name, supplier project manager] |
| Receiving support organisation | [Name, team] |
| Status | [Draft / Reviewed by support / Accepted] |
| Version | [x.y] |
| Storage location | [Link, accessible to support] |
| Related documents | [Project closure (template [IDK-24](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/24-project-closure-and-lessons-learned)), update strategy (template [IDK-23](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/23-update-strategy-evergreen)), CRIM log, interface register] |

 | Version | Date | Author | Change |
| --- | --- | --- | --- |
| [0.1] | [YYYY-MM-DD] | [name] | [First draft] |

 ## 1. Customer information

 | Field | Value |
| --- | --- |
| Legal entity and group structure | [text] |
| Industry and main business | [text] |
| Companies and sites live in IFS Cloud | [list] |
| Countries and languages in use | [list] |
| Deployment option | [Cloud service / Remote deployment] |
| IFS Cloud release and service update level at handover | [release, update] |
| Go-live date(s) | [date per site or module] |
| User base | [Named users by type: link to licence record] |
| Business-critical periods | [Period end, seasonal peaks, shift patterns] |
| Support agreement reference | [Contract, service hours, response commitments: link] |
| Further rollouts planned | [Sites, modules, dates] |

 ## 2. Project contacts

 | Role | Name | Organisation | Contact | Available after handover until |
| --- | --- | --- | --- | --- |
| Customer sponsor | [name] | [Customer] | [email, phone] | [YYYY-MM-DD] |
| Customer project manager | [name] | [Customer] | [email, phone] | [YYYY-MM-DD] |
| Customer system owner after go-live | [name] | [Customer] | [email, phone] | Permanent |
| Customer IT lead | [name] | [Customer] | [email, phone] | Permanent |
| Expert users per area | [link to list] | [Customer] |   | Permanent |
| Supplier project manager | [name] | [Supplier] | [email, phone] | [YYYY-MM-DD] |
| Solution architect | [name] | [Supplier] | [email, phone] | [YYYY-MM-DD] |
| Technical solution manager | [name] | [Supplier] | [email, phone] | [YYYY-MM-DD] |
| Application consultants per area | [names] | [Supplier] | [email] | [YYYY-MM-DD] |
| Account manager | [name] | [Supplier] | [email, phone] | Permanent |

 Who at the customer may log support cases: [names or rule]. Who may approve chargeable work: [names].

 ## 3. Handover checklist

 | # | Item | Done | Evidence / link | Comment |
| --- | --- | --- | --- | --- |
| 1 | Customer is live in the handover scope | [ ] | [Go-live confirmation] |   |
| 2 | Solution accepted by the customer | [ ] | [SAT and ORT sign-off] |   |
| 3 | Documentation is in English | [ ] |   |   |
| 4 | Process model is current and accessible to support | [ ] | [link] |   |
| 5 | CRIM log complete, with latest functional and test specifications | [ ] | [Section 6] |   |
| 6 | Third-party integrations listed with owners and accounts | [ ] | [Section 7] |   |
| 7 | Extensions and localisations listed | [ ] | [Section 8] |   |
| 8 | Environments documented; support has the access it needs | [ ] | [Section 5] |   |
| 9 | Delivery schedule and readiness reviewed | [ ] | [Section 9] |   |
| 10 | Basic data to adjust after go-live listed with owners | [ ] | [Section 10] |   |
| 11 | Known issues and workarounds listed; open cases transferred | [ ] | [Section 11] |   |
| 12 | Project accounts and elevated access removed or given an end date | [ ] | [Account list] |   |
| 13 | Handover meeting held and recorded | [ ] | [Section 12] |   |

 ## 4. Solution overview

 | Item | Value |
| --- | --- |
| Process model | [Link to the project in the IFS Scope Tool or exported model] |
| End-to-end processes in use | [list] |
| Operating model summary | [Link to the approved Book of Rules documents] |
| Key design decisions | [Link to decision log. Include the reasoning, not only the outcome.] |
| Step-by-step guides | [Library link] |
| Roles and permission sets | [Link to role matrix] |
| Lobbies in daily use | [list with owner] |
| Workflows and event actions in use | [list with purpose and owner] |

 Plain-language summary of how this customer uses IFS Cloud and what is unusual about it: [short text. This is the paragraph a new support consultant reads first.]

 ## 5. Environments

 | Environment | Place | Purpose | Release and update level | Refreshed from / when | Access for support | Owner |
| --- | --- | --- | --- | --- | --- | --- |
| [name] | [Build Place / Use Place] | [purpose] | [level] | [source, date] | [Yes / No, how] | [name] |
| Example: PROD | Example: Use Place | Example: Production | [level] | Not applicable | Example: On request through the customer IT lead, time-limited | Example: Customer IT lead |
| Example: [name] | Example: Build Place | Example: Development and delivery of modifications | [level] | [YYYY-MM-DD] | Example: Supplier technical team | Example: Technical solution manager |

 Delivery route from Build Place to Use Place production: [steps, approver, who applies deliveries]. Code repository and branch rules: [link, text]. Identity provider and single sign-on setup: [summary, owner].

 ## 6. CRIM objects handed over

 Every configuration, report, integration and modification delivered by the project. A fix cannot be verified without a test specification, so a missing link in this table is an open handover item.

 | CRIM ID | Type | Name and purpose | Process | Functional specification (link, version) | Test specification (link, version) | Version in production | Built by | Re-verify at each update |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| [ID] | [C / R / I / M] | [text] | [process] | [link, x.y] | [link, x.y] | [x.y] | [name] | [Yes / No] |
| Example: CRIM-017 | Example: Configuration | Example: Custom field "Internal project code" on purchase order line, shown on the supplier order report | Example: Procure to pay | [link, x.y] | [link, x.y] | [x.y] | [name] | Yes |
| Example: CRIM-003 | Example: Integration | Example: Outbound payment file to the bank in the agreed format | Example: Procure to pay, supplier payment | [link, x.y] | [link, x.y] | [x.y] | [name] | Yes |

 Confirmation: specifications above are the latest versions and match what runs in production. Confirmed by [technical solution manager] on [YYYY-MM-DD].

 ## 7. Third-party integrations

 Include everything that reads from or writes to IFS Cloud, also services the project did not build.

 | # | System / service | Purpose | Direction | Projections / interface used | Account and permission set | Authentication | Customer owner | Vendor contact | Check after each update | How to remove |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| [n] | [name] | [purpose] | [Inbound / Outbound / Read-only] | [list] | [account, permission set] | [method] | [name] | [contact] | [what to verify] | [steps] |
| Example: 1 | Example: External monitoring service for purchasing exceptions, supplied by a third party, running inside the customer network | Example: Alerts purchasers to orders the supplier has not confirmed and to late deliveries | Example: Read-only. Reads through OData. Writes nothing to IFS Cloud and installs nothing in it. | Example: Purchase order and supplier projections: `[projection names]` | Example: Dedicated service account `[account name]` with one read-only permission set `[permission set name]`. No end-user permission sets granted. | Example: `[IAM client / method as configured]` | Example: Procurement manager (business), customer IT lead (account) | [contact] | Example: Projections still exist and return the fields in use; service account still active | Example: Revoke the permission set, deactivate the account, stop the service. Nothing to uninstall in IFS Cloud. |
| Example: 2 | Example: Bank | Example: Payment files out, statements in | Example: Outbound and inbound | Example: See CRIM CRIM-003, CRIM-004 | [account, permission set] | [method] | Example: Finance lead | [contact] | Example: File format unchanged; test file accepted | [steps] |

 Legacy interfaces stopped at go-live: [link to the closed part of the interface register].

 ## 8. Extensions and localisations

 | Item | Type | Supplier / source | Version | Purpose | Licence or contract reference | Update dependency |
| --- | --- | --- | --- | --- | --- | --- |
| [name] | [Extension / Localisation / Partner product] | [name] | [x.y] | [text] | [ref] | [Must be updated with each release update: Yes / No] |
| Example: Country localisation for `[country]` | Example: Localisation | [source] | [x.y] | Example: Statutory reporting and tax handling for the legal entity in `[country]` | [ref] | [Yes / No] |

 ## 9. Delivery schedule and readiness

 | Delivery | Content | Planned | Status | Readiness for support | Owner |
| --- | --- | --- | --- | --- | --- |
| [Go-live scope per site or module, later rollouts, outstanding CRIM deliveries] | [text] | [YYYY-MM-DD] | [Live / Planned / In build] | [Handed over / Stays with project until: date] | [name] |
| Example: Site `[site]`, distribution and procurement | Example: All in-scope processes | [YYYY-MM-DD] | Live | Handed over | Supplier PM |

 Work that stays with the project team after this handover: [list with end dates]. Rule for routing cases during the overlap: [text].

 ## 10. Basic data to adjust after go-live

 Settings deliberately set for cutover or the first period of use, which someone must change later. If nobody owns them, they stay wrong.

 | # | Basic data / setting | Current value and why | Target value | When | Owner | Done |
| --- | --- | --- | --- | --- | --- | --- |
| [n] | [setting] | [text] | [text] | [date or trigger] | [name] | [ ] |
| Example: 1 | Example: Authorisation limits for purchase orders | Example: Set high for the first period so that approvals do not stop purchasing while approvers learn the process | Example: Limits from the approved procurement policy | [YYYY-MM-DD] | Example: Procurement manager | [ ] |
| Example: 2 | Example: Users with temporary extra permission sets granted for go-live support | Example: Expert users hold wider access during the support period | Example: Role-based permission sets only | [YYYY-MM-DD] | Example: Security lead | [ ] |

 ## 11. Known issues and workarounds

 | ID | Description | Area | Workaround in use | Case reference | Owner | Planned fix |
| --- | --- | --- | --- | --- | --- | --- |
| [ID] | [text] | [area] | [text] | [ref] | [name] | [Delivery, service update or date] |
| Example: R-006 | Example: Supplier order report shows the custom project code only on the first page | Example: Procurement | Example: Purchasers add the code to the order note for multi-page orders | [ref] | [name] | [delivery] |

 Open support cases with the software vendor at handover: [list or link]. Residual issues from the closure document: [link to template [IDK-24](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/24-project-closure-and-lessons-learned), section 4].

 ## 12. Handover meeting record

 | Field | Value |
| --- | --- |
| Date | [YYYY-MM-DD] |
| Attendees, project team | [names] |
| Attendees, support | [names] |
| Attendees, customer | [names] |
| Recording | [link] |
| Agenda | [Customer and solution overview; CRIM walkthrough; integrations; environments and delivery route; known issues; basic data to adjust; questions from support] |

 | # | Question or action from the meeting | Owner | Due | Closed |
| --- | --- | --- | --- | --- |
| [n] | [text] | [name] | [YYYY-MM-DD] | [ ] |

 Support start date: [YYYY-MM-DD]. From this date cases go to: [channel].

 ## Approval

 | Role | Name | Decision | Date | Signature |
| --- | --- | --- | --- | --- |
| Supplier project manager (owner) | [name] | [Submitted] | [YYYY-MM-DD] |   |
| Technical solution manager | [name] | [Confirms sections 5 to 8] | [YYYY-MM-DD] |   |
| Support manager | [name] | [Accepted / Accepted with open items / Rejected] | [YYYY-MM-DD] |   |
| Customer project manager | [name] | [Accepted / Rejected] | [YYYY-MM-DD] |   |
| Customer system owner | [name] | [Accepted / Rejected] | [YYYY-MM-DD] |   |

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.