Migrate from ServiceNow to iTop

Migrate from ServiceNow to iTop: what the move involves

Moving from ServiceNow to iTop is a data, CMDB model and process rebuild, not a file copy. The effort depends on how much customization your ServiceNow estate carries, such as custom tables, bespoke CI classes, flow designer workflows and catalog items. If your reason for leaving is a renewal, a residency requirement or a wish to own the CMDB model yourself, the work starts with deciding which parts of the ServiceNow model you still need and which you will retire. An internal platform team usually leads this, with an implementation partner handling the iTop data model, import pipelines and testing. iTop is AGPL-3.0 licensed, built with PHP on MySQL or MariaDB, and sponsored, led and supported by Combodo, so you will run it on a stack your team must maintain. Confirm with Combodo and your own architects whether that stack matches your database and hosting standards before you commit.

Plan the CMDB first. iTop's CMDB is fully customizable, which means your CI classes, attributes and relationships are reshaped by your team rather than transferred from ServiceNow's CMDB tables. Map each ServiceNow CI class to an iTop class, decide which relationships drive impact analysis, and agree the naming and lifecycle states before loading any records. Extracted ServiceNow exports arrive as flat files, so you will need to transform them into the structure iTop's CSV import expects, and then test the load in a non-production instance. Plan for a data consistency audit after each load, because orphaned relationships and duplicate CIs are the usual source of failure. The main risk is loading an unreviewed CMDB, which turns impact analysis into a source of false confidence. Ask any partner to show a sample migration and a reconciliation report for your largest CI class before you accept a fixed-scope quote.

Which ServiceNow capabilities map cleanly to iTop

This table compares the main ServiceNow ITSM and CMDB capabilities with what iTop's README describes, and marks each as clean, needs rework or gap. Read clean as a documented match that still needs a check against your own workflows, and treat rework as a rebuild effort that your team or an implementation partner must scope. The main takeaway is that iTop's CMDB and impact analysis are strong fits, while service catalog depth and ServiceNow-specific workflows need confirmation before you commit.

Capability	iTop position	Status and what to confirm
Incident and helpdesk	Helpdesk and incident management are listed in the iTop README	Clean. Confirm escalation rules, assignment logic and ticket volumes against your current queues
Problem management	Not named as a separate module in the README	Needs rework. Confirm whether iTop's ticket model covers known-error and root-cause records as you use them
Change management	Change management is listed in the iTop README	Needs rework. Rebuild approval paths, CAB routing and change templates to match your ServiceNow workflows
Service catalog	Service and contract management are listed, but a self-service catalog is not described as a separate feature	Gap until confirmed. Ask Combodo or test whether request forms and fulfillment flows meet your catalog needs
CMDB and CI classes	Fully customizable CMDB with relationships	Clean for modeling, but CI classes must be redesigned as iTop classes and mapped field by field
SLA management	Customizable SLA management is listed in the iTop README	Needs rework. Rebuild SLA targets, calendars and breach rules in iTop's model and test them with sample tickets
Impact analysis	Graphical impact analysis is listed in the iTop README	Clean. Validate that relationship depth from your exported CI data produces the graphs your teams use
Contract management	Service and contract management are listed in the iTop README	Needs rework. Confirm how contract, licence and renewal fields map from ServiceNow records
Bulk data load	CSV import and data synchronization for federation are listed in the README	Clean for structured records. Attachments, comments and activity history need a separate extraction plan
Reporting and integrations	Data consistency audits are listed, but report builders and API coverage are not described in the README	Gap until confirmed. Check reporting needs and integration endpoints against iTop's documentation and extensions in the iTop Hub

Which exported records move and which integrations need rebuilding

Records move through a CSV path that you reshape yourself, while attachments, workflow definitions and integrations need their own plan. The cards below separate what loads cleanly into iTop from what must be rebuilt or re-pointed, so the cutover scope is agreed before data work starts.

Export ServiceNow tables to CSV

Start by listing the ServiceNow tables that hold incidents, problems, changes, configuration items and their relationships, then export each one to CSV. Export limits on list views apply, so plan batches by table and by date range rather than assuming one export captures history. Confirm the export limits in your own instance and read the sibling export page for the options. Record the exact export date so later delta loads can be reconciled.

Reshape columns to iTop classes

Map each ServiceNow column to an iTop class and attribute before loading. Reference fields such as caller, assignment group and configuration item must be converted to the matching iTop object keys, which usually means loading people, teams and CIs first. Build a mapping sheet that names the source table, target class and any value translations, and review it with the service owners who will use the data.

Load through the CSV import

Use iTop's CSV import to load each class in dependency order, starting with organizations, locations and persons, then CIs, then tickets. Run a small test batch in a non-production instance first and check how duplicate detection and search keys match existing objects. Keep the import files under version control so a failed batch can be rerun without creating duplicates.

Run data consistency audits

After each load, run iTop's data consistency audits to find broken references, orphaned relations and CIs without an owner. Treat audit findings as a migration gate: agree with the business which findings must be fixed before cutover and which can be accepted. Document the audit results as evidence of data quality for change and CMDB reviews.

Carry attachments separately

CSV exports carry field values but not attachment files, so attachments need a separate extraction path, typically through the ServiceNow REST API. Decide which attachments are operationally needed, such as change approvals or incident evidence, and store them in a location linked from the iTop record. Confirm retention and access rules for attachments with your records and security owners before extraction starts.

Rebuild workflows and integrations

Workflow definitions, approval rules, SLA logic and catalog items do not transfer through a CSV load and must be rebuilt in iTop's customization model. Monitoring alerts, discovery feeds, identity provisioning and email-to-ticket routing also need to be rebuilt or re-pointed at iTop endpoints. Inventory every inbound and outbound integration, assign an owner for each, and test them in parallel before retiring the ServiceNow connections.

Migration sequence from inventory to decommission

The sequence moves ServiceNow CMDB, incident, change and SLA records into iTop in controlled stages, so each stage produces evidence that the next one depends on. Each step closes with a named output that the migration team signs off before work continues.

Inventory CI classes, incidents and SLAs
The migration lead and ServiceNow administrators list every configuration item class in use, the relationships between them, the active incident, problem and change workflows, and every SLA definition with its targets and conditions. Owners of each area confirm which fields are used in practice and which are legacy. The output is an inventory register that records record counts, attachment volumes and open items per table, and it is complete when each owner has signed off their section.
Build the data mapping workbook
Working with iTop administrators, the team maps each ServiceNow class and field to an iTop class, attribute or relation, and decides what to drop, merge or keep as free text. Value lists, status names and priority scales are translated into iTop's lifecycle states and enumerations. The output is a mapping workbook with one row per source field, its target, transformation rule and named owner, and it is done when the business owners of incident, change and CMDB data approve it.
Export source records within ServiceNow limits
The team extracts each table in the inventory from ServiceNow using list exports or the export method the platform supports for that volume, and extracts attachments through a separate process because list exports do not carry them. Each file is checked for row counts against the inventory register, and any truncation is logged and re-run. The output is a versioned set of source extracts with checksums and a log of every export job, and the step is complete when counts match the register.
Run a pilot load into non-production iTop
The team loads a representative subset of CIs, relations, contacts and tickets into a non-production iTop instance using its CSV import, then checks failed rows, duplicate keys and broken relations. Mapping rules are corrected in the workbook and the pilot is repeated until errors are understood. The output is a pilot report listing rejected rows by cause, the corrections made and the open decisions, and the step closes when business users have reviewed sample records in the console.
Rebuild SLAs, change workflows and impact analysis
Using the SLA inventory, the team configures service level agreements, escalation rules and change workflows in iTop, then tests them against scenarios taken from real past tickets. Impact analysis is checked by tracing known service dependencies through the rebuilt CMDB relations. The output is a configuration test record showing each SLA and change path tested, the expected and actual results, and sign-off from the service owners.
Reconcile during a parallel run
ServiceNow and iTop run side by side for a period agreed in the migration plan, while operators log new work in iTop and compare record counts, open items and CI relations between the two systems each cycle. Differences are traced to a mapping rule, a load error or a process gap and fixed at source. The output is a reconciliation report showing matched and unmatched records by table, and the step ends when the open differences are zero or explicitly accepted.
Execute cutover with a frozen data window
The team freezes change in ServiceNow for an agreed window, runs the final delta extract and load into production iTop, repeats the reconciliation checks and switches users, integrations and notification addresses to iTop. A written cutover runbook assigns each action, rollback point and decision owner. The output is the signed cutover runbook with the final reconciliation results, and the step is done when the go decision is recorded.
Archive ServiceNow records and decommission
After the agreed retention period, the team archives the final ServiceNow extracts, attachments and audit logs in storage the organization controls, confirms that the archive can be read, then removes access and disables the subscription or private instance. Retention and deletion decisions are recorded with the data owner and the compliance function. The output is an archive index with checksums, a retention record and written confirmation of decommission.

How to map ServiceNow CI classes to iTop's customizable CMDB

Decide the iTop data model before you load a single record. The class mapping is the most consequential design step in this migration, because iTop's CMDB is customizable: you define the classes, attributes and relationships your organization needs rather than inheriting ServiceNow's CI hierarchy. Start by exporting the CI classes actually in use, then count the records and relationships in each. For each ServiceNow class, decide whether it maps to an existing iTop class, becomes a new class you define, or is dropped because nothing depends on it. Involve the owners of incident, change and service catalog data in that decision, since their reports and approval routing depend on which classes exist. Record every decision in a mapping workbook that names the source table, target class, attribute and transformation, and treat that workbook as the sign-off document for the design.

Model relationships and impact paths deliberately, because iTop's graphical impact analysis is only as useful as the links behind it. ServiceNow relationships in the CMDB are often numerous and inconsistently typed, so do not copy them one for one. Define the relationship types iTop needs, such as hosts, depends on or uses, then decide which direction an impact should travel for each. Test a few representative paths end to end, for example from a database server up to the business services it supports, before bulk loading. Load the CSV files in dependency order: organizations and locations first, then the CIs, then the relationships that reference them. iTop's Combodo iTop project page describes CSV import and data synchronization for federation, which matter when some CI data stays in discovery tooling or another system. Confirm with Combodo or your own test instance which synchronization sources your version supports and how they handle deletions.

Run data consistency audits after every load, not once at the end. Audits surface missing mandatory attributes, orphaned relationships and CIs without an owner, which are the defects that break change approval and impact analysis later. Keep the audit results with the import logs so each batch can be traced back to its source export and mapping version. Plan a reconciliation step with the business owners for records that fail, because the fastest way to lose trust in a new CMDB is to load stale or duplicate CIs. Also confirm the sizing before the load: Combodo's software requirements page suggests separate web and database servers for larger installations, and the database should be sized with the import volume in mind. Ask your implementation partner to show the audit reports from a trial load so you know what a clean result looks like.

How the migration differs by estate size and starting point

A small service desk that stays within the free Community edition is the simplest case. Combodo offers iTop Community free for up to 10 agents, and its requirements page suggests a single all-in-one server with 2 vCPU and 4 GB of memory for fewer than 200 tickets a month and under 20 console users. At this size the migration is mostly a matter of mapping a short list of CI classes and loading records, and the infrastructure cost is a single small host plus its database.

Agent count: Confirm that the number of agents who will work tickets, not the number of requesters, stays at or below 10 before choosing Community.
Single server: The all-in-one layout keeps the web tier, PHP runtime and MariaDB on one host, which is simple to back up but shares resources.
Ticket volume: Measure monthly ticket volume from ServiceNow reports, since the 200-ticket suggestion is the threshold for the single-server layout.
Limited rebuild: Smaller instances usually have fewer custom workflows, so the change and SLA rebuild is shorter.
Growth path: If headcount is likely to pass 10 agents within the planning period, price Atelier before the cutover rather than after.

Before committing, ask Combodo or a partner to confirm the agent count and console user count in writing against the current edition terms.

What drives migration cost and duration

This table lists the factors that move effort on a ServiceNow to iTop migration, why each one matters, and how to reduce it. Read it before requesting a scope, because the drivers show which items a written quote should itemize separately.

Driver	Why it changes effort	How to keep it down
CI classes and relationships	Each ServiceNow CI class must map to an iTop class or a customized one, and every relationship type needs a matching definition before data loads.	Inventory active CI classes and relationships first, retire unused ones, and agree the target model in writing before any import.
Record volume and attachments	Large incident, change and CI tables take longer to export, transform and verify, and attachments need a separate extraction path from list exports.	Set an archive cut-off for closed records, split loads by table, and confirm attachment handling in the scope.
Workflow and SLA customization	ServiceNow flows, business rules and SLA definitions rarely translate one to one, so each custom workflow is rebuilt and tested in iTop's lifecycle and SLA model.	Rank workflows by business use, rebuild only the ones still in use, and document the rest as retired.
Integrations and data feeds	Every inbound or outbound integration (monitoring, identity, HR, procurement) needs a replacement or a data synchronization design and its own testing.	Build an integration register with owners and cut over feeds in phases instead of all at once.
Agents, users and edition	The number of agents determines the iTop edition (Community for up to 10 agents, Atelier for up to 50, Forge above 50), which affects licensing and support scope.	Confirm the agent count and edition with Combodo before design, and separate read-only CMDB consumers from named agents.
Hosting and PHP/MariaDB setup	iTop 3.3.x needs PHP 8.2 to 8.4, MariaDB 10.6 to 11.8 (preferred over MySQL 8) and GraphViz, and sizing differs for an all-in-one server versus split web and database tiers.	Ask for sizing against your ticket volume and console users, and include the platform build, hardening and backup setup in the written scope.
Training and process change	Agents, change managers and CMDB owners must learn new screens and approval paths, and process decisions made during migration take time.	Schedule role-based training after the target workflows are signed off, and name process owners who can decide quickly.
Parallel-run length	Running ServiceNow and iTop side by side doubles data entry risk and needs reconciliation checks at each cutover step.	Define exit criteria for the parallel run in writing, and limit it to the reconciliation scope rather than an open-ended period.

What usually goes wrong and how to prevent it

Most failed ServiceNow to iTop migrations do not fail in the software. They fail in the data model, the undocumented logic carried over from ServiceNow, and the integrations nobody listed. The cards below cover the failures we see most often and the check that prevents each one, in roughly the order they appear in a project.

Loading CMDB data without a model

Importing exported ServiceNow CI records into iTop before the target class model is agreed produces a CMDB that looks full but cannot answer impact questions. ServiceNow's CI class hierarchy and relationship types do not map one to one onto iTop classes. Before any CSV import, write the target model on paper: which classes, which relationships, which mandatory fields. Test the model with a small sample of one application and its servers, then run an impact query on it.

Duplicate configuration items

ServiceNow exports often contain the same server under several names, once from discovery, once from manual entry and once from an asset feed. Importing all three into iTop creates duplicate CIs that split incidents, changes and impact paths across records. Define the matching key per class, such as serial number, FQDN or asset tag, and run a duplicate report on the staging data. Merge or retire duplicates before the cutover, not after users start working in the new tool.

Lost history and audit trails

Exported ServiceNow records usually carry the current state of each ticket and CI, not the full history of who changed what and when. Auditors and post-incident reviews often need that history. Decide early which history is archived as read-only export files, which is imported, and where the archive lives. Ask the audit owner to sign off on that retention decision, and confirm with them how long records must remain available.

Undocumented SLA and escalation logic

Many ServiceNow SLA definitions, escalation timers and assignment rules were configured years ago and are known only to the person who built them. They do not transfer automatically. Before rebuilding anything in iTop's customizable SLA management, export the active definitions and interview the teams that rely on them. Write each rule as a plain statement of priority, target time, pause conditions and escalation target, then test it against a set of historic tickets.

Change approval paths not re-tested

Change workflows in ServiceNow often combine approval groups, risk scoring and blackout windows in ways that are easy to misread from an export. A rebuilt approval path can look correct and still route emergency or standard changes to the wrong approver. Replay a sample of past changes of each type through the new workflow, and have the change advisory board confirm each outcome in writing before go-live.

Missing integrations and agent licensing limits

Monitoring feeds, identity directories, discovery tools and email intake that worked silently in ServiceNow are often missed in the inventory. Build the integration list from firewall rules, API client records and the service accounts that call ServiceNow. Separately, check agent counts against the free Community edition limit of 10 agents before rollout, since exceeding it moves you to a paid edition. Confirm current edition terms with Combodo.

Questions buyers ask before moving from ServiceNow to iTop

How much effort and cost should we expect when moving from ServiceNow to iTop?

The cost is driven by scope, not by the iTop license, which is free to download under AGPL-3.0. The main cost components are the people who map and clean the CMDB, the people who rebuild SLAs, change workflows and notifications, the hosting for iTop and its MariaDB or MySQL database, and any support or training you buy from Combodo or a partner. The volume and quality of records you export, the number of custom ServiceNow workflows, and how many integrations must be rebuilt will move the total most. Ask any provider for a fixed-scope quote with the CI classes, record counts, integrations and deliverables listed in writing, and ask which costs recur each year, such as hosting, support subscriptions and any agent-based licensing.

How long does a ServiceNow to iTop migration take?

The timeline depends on the scope you agree, so no fixed duration applies to every estate. A migration with a small CMDB, a handful of workflows and one support team takes far less work than one with many CI classes, cross-system federation and several approval chains. Ask for the phases in writing: discovery of the current ServiceNow configuration, the iTop data model design, test loads, rebuild of SLAs and change processes, user acceptance testing and cutover. Each phase should have a named owner and an exit condition, so you can see where delays come from before work starts.

What does our team need to provide during the migration?

Your team supplies the knowledge that the data alone cannot show. You will need a business owner who can decide which CI classes and fields survive, an ITSM process owner who can confirm how incidents, changes and SLAs really work today, and a CMDB or data owner who can confirm which records are authoritative. You will also need an administrator who can grant export access in ServiceNow, a test environment for iTop, and reviewers for test loads and cutover. Plan these people for the duration of the project, because decisions made late in an iTop data model are expensive to reverse.

Can our own staff migrate from ServiceNow to iTop without a partner?

Yes, a capable internal team can do it, provided it has experience with relational data models, CSV imports, PHP and MariaDB administration, and the process design that ITSM requires. iTop is designed to be customized, and its CSV import is a practical way to load exported records, but a first-time team usually underestimates data cleansing, relationship mapping and workflow rebuild. Be realistic about the skills you have, and decide early which parts you will keep in-house, such as day-to-day administration, and which you will buy as fixed-scope work, such as the initial data model and cutover testing.

How does iTop's licensing by agent count affect our plan?

iTop licensing is tiered by the number of agents who work in the service desk, not by the number of end users. Combodo offers iTop Community free for up to 10 agents, iTop Atelier for up to 50 agents and iTop Forge for more than 50 agents, and each tier is available on premises or as SaaS. Count your agents, including part-time and shared roles, before you design the deployment, because the tier determines whether you can run the service desk on the free edition or need a paid one. Confirm current pricing and terms with Combodo, since prices are not part of this page.

Does iTop replace the full breadth of the ServiceNow platform?

No, iTop covers ITSM and CMDB work with a strong focus on configuration data, but it is not a general application platform like ServiceNow. The README describes a customizable CMDB, helpdesk and incident management, service and contract management, change management, customizable SLA management, graphical impact analysis, CSV import, data consistency audits and data synchronization for federation. Capabilities such as an application development platform, hardware and software asset management at ServiceNow's scale, and many prebuilt industry applications need separate evaluation or other tools. List every ServiceNow application you use before deciding, and check each one against iTop's documentation.

What technical requirements should our engineers check before iTop is deployed?

Your engineers should check the platform stack and sizing before any design is fixed. iTop 3.3.x requires PHP 8.2 to 8.4, supports MySQL 5.7 or later and MariaDB 10.6 to 11.8, with MariaDB preferred and MySQL 8 discouraged for performance reasons. It also needs GraphViz for the impact analysis diagrams. Combodo suggests an all-in-one server with 2 vCPU and 4 GB of memory for fewer than 200 tickets a month and under 20 console users, and separate web and database servers of up to 8 vCPU and 16 GB for larger installations. Confirm these figures against the current requirements page and test them with your own data volume.

What should we confirm about security and compliance before cutover?

Confirm who owns each control, because iTop is software you run inside your own environment and its security depends on how you deploy it. Check access control for the iTop profiles and roles that replace your ServiceNow roles, the encryption and backup of the MariaDB database, the logging of changes, and the retention of exported ServiceNow data that you no longer need. If you must meet a framework, ask your assessor which evidence they expect, and ask your provider which artifacts they will prepare. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue the reports.

Running ServiceNow and iTop in parallel without double entry

Decide the system of record before the first iTop record is created. During a parallel run, ServiceNow should remain the authoritative source for open incidents, changes and configuration items until a named cutover date, and iTop should receive copies that are clearly marked as migrated or read-only. Write this rule down with the service desk manager and the CMDB owner, and assign one owner per record class (incidents, changes, CIs, contracts). Without that rule, agents will update whichever screen they opened last, and reconciliation becomes guesswork. Confirm with your own iTop administrator which fields are editable on imported objects and whether any synchronization you configure, through data synchronization or scripted CSV loads, can overwrite local edits in either direction.

Reconcile in two passes. First, match CIs by a stable key such as the serial number or asset tag, not by name, and record each ServiceNow sys_id alongside the iTop object so later reloads update rather than duplicate. Second, reconcile open tickets by hand for the high-priority queues and by report for the rest, checking that the ticket reference, assigned group, SLA target and linked CI survived the load. New records need a rule too: new incidents, changes and CI registrations created after the initial load go only into iTop once it is the system of record for that class, and any ServiceNow record created during the overlap is re-keyed in iTop rather than retyped from memory. Illustrative example: a laptop record that exists in both systems should appear once in iTop, with a note pointing to the retired ServiceNow reference.

The freeze window at cutover should cover new record creation, edits to CIs and relationships, change approvals in flight, and the final incremental export from ServiceNow. Keep the window short enough that approvers and agents can work from one system at a time, and plan a rollback point if the final reconciliation fails. Export attachments separately, since list exports do not carry them, and confirm the export limits and format options in your ServiceNow release before you commit to a date. Confirm sync and export behavior in your own environment instead of assuming it, and record the results in the cutover checklist.

How DeployOpen scopes and runs the migration

The sequence turns a ServiceNow estate into a documented, backed-up iTop instance in your own infrastructure, with each stage closed by a written check before the next one starts.

Agree scope and deliverables in writing
DeployOpen reviews the ServiceNow scope with your ITSM owner, CMDB owner and security team: which tables, CI classes, SLAs, change workflows and integrations must move, and which will be retired. The output is a written scope with named deliverables, acceptance criteria and a list of open questions. Work starts only after both parties sign that document, and any change to it goes through a written change request. Ask for the scope to state what is excluded, such as attachments or custom scripts, so nothing is assumed to have moved.
Inventory the ServiceNow estate and export data
Your team exports the ServiceNow records in scope using the export methods your instance supports, and DeployOpen inventories what came out: record counts per table, CI classes, relationships, attachments and workflow definitions. The check is a reconciliation sheet that matches each exported table to a count taken in ServiceNow, with gaps listed as open items. Records that cannot be exported cleanly are flagged now, not after cutover.
Map CI classes and relationships to iTop
DeployOpen maps each ServiceNow CI class, field and relationship to an iTop class, attribute or relation in a written mapping specification, and marks each row as direct, transformed or rebuilt. Your CMDB owner approves the model before any import runs. Impact analysis paths are tested against a sample set of services so the approved model can answer the questions your change board asks. The output is a signed mapping document that lists every ServiceNow table in scope.
Build the iTop environment in your infrastructure
DeployOpen installs iTop in your own cloud accounts, data center or air-gapped network, using the PHP, MariaDB and GraphViz requirements published for the version you select. The build covers TLS, authentication, backups, logging and access restricted to your networks, and each control is recorded in the runbook. Sizing follows the Combodo guidance for an all-in-one server or separate web and database servers, depending on your ticket volume and console users. Ask your team to confirm the platform licence tier that matches your agent count before go-live.
Load, reconcile and rebuild in a test instance
DeployOpen loads exported records through iTop's CSV import in trial batches, runs data consistency audits after each batch, and reconciles counts against the mapping document. SLAs, change workflows, notification rules and service catalog entries are rebuilt from the ServiceNow design and tested with real request types from your teams. Defects are logged with owners and fixed before the next batch. The check is a reconciliation report with zero unexplained differences and a signed test result from your service owners.
Harden, document and prepare cutover
DeployOpen applies the hardening baseline agreed in scope, documents the architecture, configuration, data mapping, operations and recovery procedures, and prepares the cutover plan with a rollback path. Backup and restore are tested by restoring to a separate host, not by reading backup logs. Evidence for any compliance assessment is collected in a form your auditors can review. DeployOpen prepares this material but does not issue audit reports or certifications; independent auditors and certification bodies do that work.
Cut over and hand over to operations
Your team freezes ServiceNow changes for the agreed window, DeployOpen runs the final load and reconciliation, and your service desk switches to iTop with the rollback path held open until the sign-off criteria are met. Operators are trained on the rebuilt workflows, and the handover pack lists owners, runbooks and open items. The output is a written acceptance sign-off from your ITSM owner and the closure of the cutover checklist.
Agree optional retainer support after cutover
After handover, you can choose a retainer for upgrades, patching, backup verification, extension management and continued testing, with scope and frequency written into the agreement. Without a retainer, your team owns those tasks, and the handover pack says so explicitly. Ask for the retainer terms to name response expectations and what counts as in scope before you sign, since these vary by agreement.