Migrate from Freshservice to iTop: what moves, who does the work and how risky it is
Moving from Freshservice to iTop is a data modeling project before it is a software project. The migration starts with a conversion step: Freshservice's full service desk export arrives as XML at the registered agent email address, and that XML has to be mapped into iTop's data model and its CSV import format before any record lands in iTop. Most of the effort sits in deciding how tickets, requesters, assets, contracts and SLA definitions map onto iTop's objects, then testing those mappings on a copy of the data. Installing iTop on a server that meets the published requirements is the smaller task. Teams usually come to iTop because they want a configurable CMDB at the center of service management, so the migration is also the moment to decide which configuration items, relationships and lifecycle states will carry the impact analysis they expect.
The work is usually shared between an IT service owner, who decides which processes and SLAs must survive the move, a CMDB owner, who defines the asset and configuration item model and the reconciliation rules, and an iTop administrator, who builds the import, the workflows and the change and SLA rules. Teams without that skill set often bring in an implementation partner for the conversion scripts and the first test cycle, which is a scoped engagement that should be priced from a written scope. Risk is moderate and concentrated in three places: ticket history that loses its links to requesters and assets during conversion, asset records that duplicate because discovery and manual entry disagree, and SLA or change approvals that were implicit in Freshservice settings and never written down. Confirm with your own administrators which of these you will rebuild and which you will retire before the first import run.
Which Freshservice capabilities map to iTop, and which need rework
This table compares the Freshservice capabilities a service desk typically depends on with the iTop modules that would carry them after migration. Each row is marked clean, needs rework or gap, with notes on what to rebuild by hand. Treat every mapping as a hypothesis to confirm in a pilot, because Freshservice portal and automation behavior varies by configuration.
| Capability | iTop equivalent and status | Migration notes |
|---|---|---|
| Tickets, requesters and agents | Helpdesk ticket classes with contacts and teams. Needs rework | Freshservice requesters map to iTop contacts or persons, and agents to user accounts. Confirm how requester and agent roles, groups and notification rules translate before importing ticket history. |
| Assets and CMDB relationships | Configuration items with relations and graphical impact analysis. Needs rework | iTop's README describes a fully customizable CMDB and graphical impact analysis. Freshservice assets do not carry over automatically, so define the classes, attributes and relations first, then load assets with CSV import. |
| SLAs and escalations | Customizable SLA management in the iTop data model. Needs rework | The README describes customizable SLA management. Recreate each Freshservice SLA target, business hour calendar and escalation rule by hand and test them against sample tickets before cutover. |
| Change management | Change management module with approval steps. Needs rework | Rebuild Freshservice change types, approval flows and CAB steps as iTop lifecycle states and stimuli. Confirm that approval routing matches your process before retiring Freshservice change records. |
| Problem management | Problem records linked to incidents and changes. Needs rework | Problem records and their links to incidents are not part of the XML export as a ready structure. Plan a mapping table and verify linked records after import. |
| Knowledge articles | Knowledge content via custom classes or documents. Gap | Confirm with iTop documentation how knowledge articles, categories and publishing states are represented. Many teams keep articles in a separate wiki and link them from tickets. |
| Automation, service catalog and portal | Workflows and custom request forms need configuration. Gap | Freshservice automation rules, self-service portal layouts and catalog forms do not have a one-to-one match. Confirm each rule with iTop's documentation or a pilot before assuming an equivalent exists. |
| Reporting and data imports | CSV import, data consistency audits and data synchronization. Clean | CSV import handles bulk loading of assets and contacts. Use data consistency audits after each load and confirm that the Freshservice XML export contains the fields you need to rebuild history. |
Which Freshservice data moves into iTop, and which integrations to rebuild
Moving to iTop is four groups of work: converting the export, mapping tickets to iTop objects, rebuilding the CMDB and reconnecting integrations. Each group depends on what the export actually carries, so confirm that before estimating effort.
Converting the XML account export
A Freshservice account administrator requests the full export from Admin, Account, Export, and the data arrives as XML at the registered agent email address. iTop imports CSV, so the XML must be flattened into one CSV per object class, with stable keys so that relationships such as ticket-to-asset and person-to-team resolve on import. Confirm the export's element structure on a sample before writing any transformation.
Confirming conversation fields and attachments
Before scoping the conversion, confirm which conversation fields the export carries, such as public replies, private notes and timestamps, and whether attachments are included. Ticket history is only useful in iTop if replies and notes map to its log entries with authors and dates intact. Gaps found here change the amount of work more than any other single decision, so ask Freshservice support in writing and test with a sample.
Mapping tickets to iTop objects
Freshservice requesters, agents, groups, tickets and problems need target iTop classes, such as persons, teams, user requests and incidents, with status and priority values translated into the states defined in your iTop data model. Decide early whether closed history is imported or archived, because each imported ticket also requires its linked people and organizations to exist first. Document each mapping in a shared sheet and review it with the service desk lead.
Rebuilding the asset CMDB
Inventory from Freshservice's asset module is a starting point, not a finished CMDB. Reconcile exported asset records with current discovery data from your own tools, remove duplicates and assign owners before loading, since iTop's impact analysis depends on accurate relationships between servers, applications and services. Plan the CMDB load as a separate step from ticket import so each can be verified on its own.
Reconnecting directory, monitoring and email
Freshservice integrations such as directory sync, monitoring alerts and email intake do not move with the data. Each one must be rebuilt against iTop's own interfaces, and iTop's CSV import and data synchronization features can cover some feeds, but the connectors themselves need to be confirmed for your sources. Test email intake with a copy of the production mailbox so that requester identity and ticket threading behave as they do today.
Recreating SLAs and change workflows
Freshservice SLA policies and change approval steps are configured in its own model and must be redefined in iTop, which offers customizable SLA management and change management. Write down the current response and resolution targets, approval chains and emergency change rules before rebuilding them, since they are not portable by export. Ask the iTop implementer to walk through each rule against a test ticket with your approvers.
Migration sequence from inventory to decommissioning Freshservice
This sequence moves Freshservice tickets, assets, SLAs and change workflows into iTop in controlled stages, so each phase produces evidence that the next phase depends on before Freshservice is switched off.
Inventory Freshservice configuration and integrations
The Freshservice administrator and the IT service owner list every active configuration item: agent groups, ticket fields, custom fields, SLA policies, automation rules, change and approval flows, service catalog items, and every integration such as directory sync, monitoring alerts, email forwarding and discovery tools. Each item is tagged as keep, rebuild or retire. The step is done when the inventory is signed off by the service owner and every integration has a named owner in the target design. Confirm with Freshservice support which configuration can be exported at all, since the full export covers the service desk data rather than every setting.
Export data and build the field mapping
The administrator runs the full service desk export from Admin, Account, Export, and receives the XML at the registered agent email address. The migration lead then maps each Freshservice field, status, priority, requester, agent group and asset relationship to an iTop class, attribute or lifecycle state, and records any field that has no equivalent. The output is a reviewed mapping document and a set of sample records from each export file. The step is complete when the mapping has been checked by a second person who knows the iTop data model and the open questions list is empty or assigned.
Model classes, lifecycles, SLAs and change workflows on a test server
The implementation team builds the iTop data model on a test server: CMDB classes for the asset types the business uses, service and contract records, the ticket lifecycles for incidents and requests, SLA definitions and escalation rules, and change workflows with their approval steps. The test server should meet iTop's requirements for PHP 8.2 to 8.4, MariaDB 10.6 to 11.8 (MariaDB is preferred, and MySQL 8 is discouraged for performance reasons), and GraphViz. Combodo's requirements page 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, so confirm the expected load against that baseline. The step is done when a test ticket moves through each lifecycle and SLA clock, and the change approval path has been walked end to end by a sample approver.
Convert exports and import into a staging instance
The team converts the Freshservice XML export into the CSV layout that iTop's import accepts, one file per class, with stable external keys so that relationships between tickets, requesters and assets resolve correctly. The conversion is scripted and kept under version control so it can be rerun after corrections. The CSV import runs against a staging instance built with production-equivalent sizing, not the test server. The output is an import log showing row counts per class, rejected rows with reasons, and a short list of records that were corrected by hand. The step is complete when a rerun from a clean database produces the same result.
Run the consistency audit and reconcile errors
The team runs iTop's data consistency audits against the staging data and checks orphaned tickets, assets without an owner, contracts linked to nothing, SLA clocks that point to missing policies and requesters without a person record. The service owner reviews a sample of tickets from each status and priority to confirm that history, comments and attachments made it across. Each audit finding is either fixed in the source data, fixed in the mapping or accepted with a written reason. The step is done when the audit shows no open findings in the classes that matter for the pilot, and the owner has signed the reconciliation record.
Pilot with a small team
A small group of agents works real but low-risk requests in iTop on a production-grade server while the rest of the desk stays in Freshservice. The pilot tests logins and directory integration, notification emails, SLA timers, change approvals and the CMDB relationships that the team uses daily. Issues are logged with a severity and retested after each fix. The step is complete when the pilot group has run the agreed scenarios from the test plan without a blocking defect and the service owner has approved the move to a parallel run.
Run both systems in parallel and cut over
For a defined period agreed in advance, new work is recorded in iTop while Freshservice remains available for reference, and the team compares the two systems daily for missing tickets, duplicate notifications and SLA differences. Integrations are switched to iTop one at a time, starting with the least critical. Cutover is a scheduled change with a rollback plan, a final incremental import of tickets created during the parallel run, and a sign-off by the service owner. The output is a cutover record showing that all active integrations point to iTop and that no new tickets are created in Freshservice.
Decommission Freshservice and retain the archive
Once cutover is signed off, the team takes a final full export from Freshservice, stores it with the migration evidence under the organization's retention policy, removes API keys and agent accounts that are no longer needed, and cancels the subscription through the contract owner. The iTop backup and restore procedure is tested on the production server before the old system is closed. The step is done when the archive is verified, the subscription end date is confirmed in writing by Freshservice, and the decommission record is filed with the service owner. Ask Freshservice to confirm in writing how long it retains account data after cancellation.
How the migration changes by team size and CMDB maturity
iTop Community is free for up to 10 agents, according to Combodo's edition tiers. A small team on this edition usually has a short list of asset classes, a limited number of SLAs and a small set of change types, so the migration is mostly a question of scope discipline. Convert the Freshservice XML export into iTop's CSV import format for the tickets you still need, and import only the assets that people actually use. Keep the first configuration close to the defaults so that the data model stays easy to maintain.
- Agent count check: Count agents against the Community limit before you commit, because growth above 10 agents moves you to a paid edition.
- Ticket history: Decide how many closed tickets to carry over, and archive the rest as read-only exports.
- Asset classes: Start with the classes you already track in Freshservice, such as computers, software and contracts, and add more only when a real report needs them.
- Single server: Plan for the all-in-one layout that Combodo suggests for small installations, with the database and web tiers on one host.
- Own administration: Budget the time an internal admin needs to maintain the data model, extensions and backups, since there is no vendor administration by default.
Before you start, confirm the 10-agent limit and the all-in-one sizing directly with Combodo, because edition terms change.
Atelier covers up to 50 agents and Forge covers more than 50, and both are available on premises or as SaaS from Combodo. A mid-sized team usually has several queues, separate change approval paths and SLAs that differ by service, so the migration needs a fuller design. The Freshservice XML export becomes the source for tickets and requesters, but SLAs, change workflows and service catalog entries must be rebuilt in iTop's data model rather than copied across. Plan a pilot queue before moving the whole desk.
- Deployment model: Decide between on-premises and SaaS early, because it affects who runs the database, backups and upgrades.
- Separate tiers: Use separate web and database servers at the scale Combodo describes for larger installations.
- SLA rebuild: Recreate each SLA as an explicit definition with its own targets and escalation rules, and test it on sample tickets.
- Change workflows: Model each change type, its approvers and its lifecycle, rather than mapping Freshservice's stages one to one.
- Extensions and integration: Review the iTop Hub for extensions and list the integrations, such as directory sync or monitoring, that must be replaced.
Ask Combodo or a partner for a written scope covering edition, deployment model, data volumes and the SLA and change models you expect to build.
An organization with an accurate CMDB already has current records of configuration items, owners and relationships, so the work moves toward validation and mapping. The main task is to map existing items to iTop classes and relationships, then run consistency checks that confirm each item has an owner, a status and the links that impact analysis needs. Because iTop includes data consistency audits and graphical impact analysis, this is the stage where those features pay off. Import in batches and reconcile counts after each batch.
- Class mapping: Map each Freshservice asset type to an iTop class and document any fields that do not transfer.
- Relationship rules: Define which relationships, such as service to server or contract to asset, must exist before go-live.
- Consistency audits: Run the built-in audits after each CSV import and fix errors at the source.
- Impact analysis: Test graphical impact analysis on two or three critical services to confirm the relationships are usable.
- Import order: Load organizations and people before assets, and assets before tickets, so references resolve.
Ask Combodo or a partner how the import will handle relationship references and what audit output you can expect before you sign off the data.
An organization that must discover assets first starts with inventory rather than configuration. iTop does not replace a discovery tool by itself, so the plan needs a source of truth for computers, software and network devices. Many teams pair iTop with a discovery or inventory tool and load its output, then add ownership, services and relationships by hand or through agreed rules. Expect the first phase to produce a partial and uneven CMDB, and treat that as the baseline to improve rather than a failure.
- Discovery source: Choose the inventory tool that supplies hardware and software data, and confirm it can export into a format iTop can import.
- Ownership gaps: Plan a process to assign owners to discovered items, because undiscovered ownership blocks change and incident routing.
- Phased scope: Load servers and critical services first, then end-user devices, to limit the early cleanup load.
- Duplicate handling: Set rules for matching records from discovery against existing entries to avoid duplicates.
- Ongoing sync: Decide whether data synchronization will keep iTop current or whether imports stay periodic.
Ask Combodo or a partner which discovery sources they have tested with iTop and what they recommend for matching and deduplication.
What drives the cost and duration of moving to iTop
This table lists the factors that raise or lower the effort of moving from Freshservice to iTop, with the reason each one matters and how to keep it under control. Read it before requesting a quote, because the scope decisions behind each row set most of the one-time work and the recurring operating load. Most of the cost comes from mapping and cleaning data, not from installing iTop.
| Driver | Why it moves cost or effort | How to keep it down |
|---|---|---|
| Tickets and attachments to convert | Freshservice's full XML export arrives as a file, and each ticket's history, notes and attachments must be mapped to iTop's CSV import format. Large volumes raise conversion, validation and storage work and lengthen the test cycles. | Decide which closed tickets stay in Freshservice as an archive. Migrate open tickets and recent history, and confirm with your team which attachments are actually needed. |
| Depth of CMDB and relationship modeling | iTop's CMDB is fully customizable, so every asset class, attribute and relationship you keep (for example, servers to services to contracts) must be designed and loaded. Deep models add design, data cleansing and impact-analysis testing. | Start with the classes your incident and change processes use. Add relationships in a second phase, and run data consistency audits before loading production records. |
| SLAs and change workflows to recreate | Freshservice SLAs and approval flows do not transfer automatically. Each SLA, escalation and change path has to be rebuilt in iTop's customizable SLA and change management model and then tested against real scenarios. | Inventory current SLAs and approvals first, then cut the list to the ones auditors and business owners rely on. Retire unused automations rather than rebuilding them. |
| Integrations to rebuild | Connections to monitoring, identity, email and HR systems depend on API or import logic that must be redesigned for iTop, and each one needs its own test and failover plan. The number of integrations is usually the least predictable driver. | List every system that creates or updates tickets or assets, then ask which feeds can be replaced by iTop's CSV import or data synchronization. Keep integrations that carry no business value out of scope. |
| Hosting: all-in-one or separate servers | 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. Separate web and database servers of up to 8 vCPU and 16 GB suit larger installations, so the choice changes both build and recurring infrastructure cost. | Size from your actual monthly ticket volume and console user count, then check the iTop software requirements page for PHP, MariaDB and GraphViz versions before buying hardware or cloud capacity. |
| Extensions from the iTop Hub | Some needs, such as particular connectors or reporting, may require extensions distributed through the iTop Hub. Each extension adds evaluation, licensing check, compatibility testing and upgrade effort every time iTop is updated. | Confirm early which Freshservice features you truly need, prefer core iTop functions where they meet the need, and list every extension in the written scope with its version. |
| Licensing by edition | iTop Community is free for up to 10 agents. iTop Atelier covers up to 50 agents and iTop Forge covers more than 50, each available on premises or as SaaS. Agent count therefore decides which edition, and which support contract, applies. | Count the agents who will hold write access, not total staff, and ask Combodo to confirm edition terms and any support tier in writing before the scope is signed. |
| Internal admin time | Your administrators must supply exports, approve mappings, test workflows and sign off cutover. Delays in their availability extend the project and often cost more than the technical build itself. | Name a data owner and a workflow owner for each area, book test windows in advance and agree in the written scope which decisions your staff must make. |
What usually goes wrong when moving from Freshservice to iTop
Most migration problems start before any data moves, in the export, the data model or the server stack. The cards below cover the failure points we see most often when IT teams move ticket history, assets, SLAs and approvals into iTop, with a prevention step for each.
Incomplete export loses history
Freshservice delivers the full service desk export as XML to the registered agent email address, so an export started from the wrong account or an email that never arrives can leave gaps. A ticket import without conversation threads keeps the subject line but drops the reasoning behind each decision. Before cutover, confirm that the XML covers tickets, notes and attachments, and spot-check a sample of long-running incidents against the source system.
Duplicate or orphaned CIs
Importing asset CSVs into iTop without a stable key creates a second copy of every server that already exists, and relationships to the old copies become orphaned. Decide which attribute identifies a configuration item (serial number, hostname or asset tag) before the first import, run a test import into a copy of the database, and use iTop's data consistency audits to find records without owners or links.
SLA clocks and business hours drift
Freshservice SLA targets, pause rules and business hour calendars do not transfer automatically, so tickets can start breaching earlier or later in iTop than they did before. Rebuild the working-hours calendar, holidays and escalation steps in iTop first, then replay a set of closed tickets from the last quarter and compare the computed deadlines against the original values.
Requesters and agents do not reconcile
Person records in the two systems rarely match one to one. Duplicate requesters, agents who left the organization and shared mailboxes all produce tickets that point to the wrong person or to no one. Map people by a unique email address, merge duplicates before importing tickets, and assign each agent a profile and team that matches their current role.
Change approvals rebuilt without roles
Approval chains that worked in Freshservice often depend on informal roles, such as the change manager or the owner of a service. In iTop, an approval step with no assigned role or with the wrong profile will either stall or pass without review. Document each change type, its approvers and its emergency path, then test a standard, normal and emergency change with real users before go-live.
Database stack outside supported versions
iTop 3.3.x requires PHP 8.2 to 8.4 and 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 diagrams. Confirm the operating system packages against the iTop software requirements before building the servers, because an unsupported PHP or database version can block installation or the impact analysis views.
How to run Freshservice and iTop in parallel and cut over safely
Run Freshservice and iTop in parallel only for a short, planned window, and decide queue by queue which work stays in Freshservice and which moves. Keep in-flight incidents, major changes and anything under an open SLA clock in Freshservice until they close, because iTop will not inherit their clock or approval history from the export. Move new requests for low-risk queues first, such as standard service requests and asset updates, so the team learns the iTop forms and SLA rules on work that cannot cause an outage. Agree in writing which system is the record for each ticket type during the window, and name one owner who can rule on disputes. Confirm with the iTop administrator which iTop user profiles and team assignments exist before the first agent logs in, since missing profiles are a common cause of tickets that nobody can see.
Redirect inbound email only after the iTop mailbox connector has been tested with a copy of real traffic, and keep the Freshservice address forwarding to iTop rather than deleting it. Tickets open in both systems need a single rule: close the Freshservice copy with a pointer to the iTop reference, never edit both. Take the last incremental extract from Freshservice after the mail change has been live long enough to catch stragglers, then load it with the same field mapping used for the full import and reconcile counts by status and requester. Confirm the current export options and file formats in Freshservice's own documentation before you schedule that extract, since the admin export procedure is the source of truth for what arrives.
The cutover checklist runs in this order: final export from Freshservice, final import into iTop, data audit in iTop against the export counts and asset records, then the DNS or mail routing change, and finally a notice to users saying where to raise requests and how open tickets were carried over. Keep the Freshservice instance read-only and retained, not deleted, until the audit is signed off and your retention policy is satisfied. Rollback means reverting mail routing to Freshservice, reopening the Freshservice queues, and replaying any iTop tickets created after the cutover by hand, so record every change made after the cutover timestamp. Ask your iTop implementation partner to write this rollback path into the cutover runbook and to rehearse it on a copy of production before the real switch.
How much effort does a Freshservice to iTop migration take?
How much effort does a Freshservice to iTop migration usually take?
Effort depends mainly on how much data you carry over, how clean it is, and how many processes you rebuild. No researched figure for total effort is available, so treat any number from a vendor or partner as a claim to test. The largest drivers are the number of asset records that need reconciling, the volume of tickets you want as history rather than as an archive, and how many SLAs, approval paths and change types must be recreated in iTop's data model. Ask for the effort split by phase: export and conversion, CMDB rebuild, workflow and SLA design, testing, and cutover. Ask which of those phases is fixed in the written scope.
Can an internal IT team migrate from Freshservice to iTop on its own?
Yes, a team with PHP, MySQL or MariaDB and CSV experience can install iTop and load data, but the hard part is design, not installation. iTop's software requirements call for PHP 8.2 to 8.4, MySQL 5.7 or later or MariaDB 10.6 to 11.8 (MariaDB preferred), and GraphViz, and 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. Your team also needs time to convert Freshservice's full XML account export into iTop's CSV import format, which Freshservice delivers to the registered agent email address. Be honest about whether anyone has time for that work alongside daily operations.
What does the migration require from our own staff?
The migration needs named people who can make decisions, not only install software. Typically this means a CMDB owner who defines classes, relationships and asset lifecycle states, process owners for incident, request, change and problem handling, and an approver who signs off data mapping, SLA definitions and the cutover plan. Without these roles, iTop's flexible data model tends to be configured twice. Agree on who signs off each deliverable in writing before work begins, and state how many working sessions you expect each role to attend.
What does a fixed-scope DeployOpen engagement cover for this migration?
Most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. For a migration like this, a written scope usually names the iTop installation in your environment, the conversion of Freshservice exports into iTop CSV imports, the CMDB model you approve, the SLA and change workflows to be recreated, the testing you accept, and the cutover and rollback steps. It should also state what is out of scope, such as portal branding, custom integrations or historical attachments. DeployOpen does not publish a price list, so a quote follows from that written scope.
What recurring costs remain after iTop goes live?
The iTop software itself is AGPL-3.0 and has no license fee in the Community edition, which is free for up to 10 agents. Recurring costs are the hosting and database servers, backups, patching and upgrades, staff time for administration, and any paid tier you choose: Combodo offers iTop Atelier for up to 50 agents and iTop Forge for more than 50 agents, each on premises or as SaaS, with commercial support and training sold separately. Ask Combodo for current paid edition terms, and ask any partner whether upgrades and continuous support are a retainer.
Can iTop replace Freshservice's portal and automation features?
iTop covers the core ITSM model, including helpdesk and incident management, service and contract management, change management, customizable SLA management, and CSV import, but you should confirm each feature you depend on before committing. Freshservice's self-service portal, workflow automator and integrations may map to iTop extensions, which are distributed through the iTop Hub, or to custom development. Build a feature inventory from your current Freshservice configuration, mark each item as native, extension or custom, and test the riskiest ones first in a non-production instance.
What should we ask for in a migration quote?
Ask for a quote built from a written scope with these items: the environment and sizing assumptions, including the server tiers Combodo describes for small and larger installations; the data sources, with the Freshservice XML export and any CSV ticket exports named; the CMDB and process design deliverables; the SLA and change workflows to be rebuilt; the testing and acceptance criteria; the cutover and rollback plan; and the handover and documentation. Ask which items are one-time and which recur, and whether backups and upgrades are included or billed as a retainer.
How DeployOpen scopes, runs and supports an iTop migration
DeployOpen plans, implements, customizes, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure, including iTop. For a Freshservice move, we start with a written scope that maps your tickets, assets, SLAs and change workflows to iTop's data model before any data is loaded.
How we scope
- Inventory the Freshservice XML export, ticket CSVs and asset records you intend to keep.
- Agree in writing which ticket history, requesters, agents and asset classes move into iTop.
- Confirm iTop edition, hosting location, PHP and MariaDB versions, and agent count before build starts.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.
How we build
- Convert the XML account export and ticket CSVs into iTop's CSV import format, then test on a copy.
- Rebuild the CMDB classes, asset relationships and contracts that your service catalog depends on.
- Recreate SLA, escalation and change workflows in iTop's data model and check them against your current rules.
- Run data consistency audits and impact analysis checks to confirm imported records behave as expected.
How we hand over
- Document the field mappings, import steps, configuration and known gaps against Freshservice behavior.
- Deliver a cutover plan covering the final export, reconciliation checks and rollback options.
- Provide operator runbooks for backups, upgrades and the iTop server components you will run.
- Walk your administrators through the rebuilt workflows and confirm acceptance against the written scope.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover.
- Plan iTop upgrades and extension changes, including those distributed through the iTop Hub.
- Review backup restores and configuration drift on a schedule agreed in your retainer.
- Route commercial iTop support, training and consultancy questions to Combodo where they apply.
