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.

Template metadata
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

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), update strategy (template IDK-23), 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
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, 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
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.

Marketplace