Comup migrates complete service operations from ServiceNow, BMC Remedy, IBM Maximo and Zendesk to Freshservice and Freshdesk — history, comments, attachments, contacts, assets and knowledge — validated record by record, without stopping your operation.
of ITSM teams have already replaced their tool or plan to do so as soon as they can (ITSM.tools, 2025). The question is no longer whether you migrate — it is how you arrive with your full history intact.
We do not start from zero on each project: these are the routes the team has already completed — or is running right now — with their real volumes.
Full migration of the service operation to Freshservice, with its history and the operation running throughout.
From an asset platform to a modern service desk, under a multi-year Enterprise agreement.
Program sized on real data: 15,490 incidents, 11,850 contacts and 1,397 changes from the last year, moving to a historical-consultation instance.
Migration of the support operation to Freshdesk Omni, in progress.
Customer-care history moving to Freshdesk Omni, as the second front of the same program.
If your desk lives on Jira, Cherwell, ManageEngine or another platform, the route is designed with the same method: inventory, mapping and a pilot before committing to the cutover. And if your system has no API, the alternate route is a structured file (CSV).
The detail a CIO needs to sign with confidence: this is what travels, field by field.
We operate specialized migration platforms — the same ones large programs use — inside a consulting method.
Before anything is committed, a sample of your own tickets, contacts and articles migrates and is reviewed with you. What you see in the pilot is what happens in the full migration.
The specialized platforms we operate auto-map the large majority of fields; the fine tuning — custom fields, lists, multi-selects — is signed off by a consultant, not an algorithm.
Your team keeps working on the source platform during the process: at cutover, only what is new or updated since the full migration travels. Nothing is captured twice.
The transfer can pause and resume to respect your peak hours and operating windows.
We work with migration platforms holding SOC 2 Type II certification and API connections: your data does not travel in loose spreadsheets or emails.
A legacy or in-house system without connectors? The migration runs from a structured file, preserving the relationships between records.
Several desks or regions on separate platforms — or an acquisition to merge? We consolidate two or more instances into one, tagging every record with its origin so reporting and audits still reconcile.
When standard mapping is not enough: problems and changes that travel as tickets, tasks that land as private notes, the legacy ID inside the subject, CC emails converted into a field. Every adjustment is quoted upfront, with the pilot as evidence.
Your next platform will not be used by people alone: AI agents will answer from your data. A migration that ignores that plants wrong answers.
We filter out outdated records and normalize tags, fields and internal notes: the AI agent learns from an orderly operation, not from years of noise.
If your knowledge lives in several bases, it merges into one clean, consistent source — the one Freddy and your agents will consult.
The knowledge base and recent tickets migrate first: you validate the AI on live data before the full history lands.
Five steps, with evidence at each one. The cutover is the last step, not the first.
Inventory of volumes, fields and business rules; the source → target mapping design is signed off before a single record moves. Deliverable: the map and the cutover plan.
A representative sample migrates first and is reviewed with you, field by field. Deliverable: a pilot report with migrated, skipped and failed records.
The bulk of the history moves with specialized platforms while your operation keeps serving. History first; the most recent records, last.
Count reconciliation — source against target — plus record-by-record sampling. Nothing is declared migrated without proof. Deliverable: the reconciliation report.
A final delta of the latest changes, an agreed, after-hours cutover window: your team ends its day on the source platform and starts the next one on the new platform. Close support continues until the operation stabilizes.
A tool moves data. Migrating an operation is something else — and it is exactly where a partner earns its place.
Business rules, approval flows, SLAs and orchestrations are each platform's own logic. They are redesigned on the target — and it is the chance to leave years of dead rules behind.
Service catalogs and forms are rebuilt on the target's structure, designed for the self-service and AI that come next.
Duplicates, orphaned contacts and abandoned fields do not travel. Upfront cleaning defines which history is worth keeping — and lowers the cost of the whole program.
Training, communication and go-live support: a technically perfect migration fails if the team does not adopt it.
Five decisions that speed up any migration program.
No. The full and delta migrations run while your team keeps serving on the source platform. Only the final cutover uses a short, agreed window.
The technical transfer of the data takes days. The full program — assessment, pilot, migration, validation and cutover — typically takes 4 to 7 weeks. Transfer time is driven by volumes, attachment weight and the API limits of both platforms (which can be raised temporarily to speed up the cutover).
Dates and the timeline, yes. The target assigns new IDs; the original number is kept in a cross-reference field, forever findable.
They travel with their record: attachments, inline images and evidence stay linked to the ticket on the target.
Yes: the pilot with your real records is part of the method and happens before the full migration. And the initial assessment — inventory, route and window — carries no obligation.
Freshservice's native importer, for example, covers contacts via CSV. A real operation needs tickets with history, conversations, attachments, custom fields, changes and knowledge — with mapping and validation. That is the difference between importing data and migrating an operation.
It is the classic scenario after an acquisition or a regional restructure: one migration runs per source into the single instance, with every record tagged by origin. It also works in reverse: splitting a brand or region into its own instance.
Your desk keeps serving throughout the process; the cutover is planned in your window, not ours.
Every migrated volume is reconciled against the source. If a number does not match, we do not move on.
The same people who map your operation run the cutover and the hypercare.
We operate from Vancouver, Mexico City and Madrid, with projects in five countries and support in Spanish and English.
A migration assessment in one executive session: inventory, route and cutover window, with no obligation.
Book your assessment