How Minebea Intec Moved 12 Years of Incidents from TOPdesk to ManageEngine ServiceDesk Plus Against a Contract Expiry

TL;DR

Customer: Minebea Intec (industrial weighing and inspection technology, Hamburg. Over 150 years old, part of the MinebeaMitsumi group, with sites across Europe and Asia.)

The Move: TOPdesk to ManageEngine ServiceDesk Plus Cloud (EU data centre). All incidents including archived, plus notes, attachments, persons, operators, departments, branches and locations. The audit progress trail was excluded at the customer's request.

The Scope: Roughly 109,000 incidents, over 450,000 notes, roughly 247,000 attachments, and around 1,100 contacts. Twelve years of service history.

The Roadblock: The ManageEngine instance was live production, not a sandbox — so every mapping had to be right before the first write, not corrected after it. ManageEngine silently drops a field whose value does not exist rather than rejecting the request, which means a wrong mapping produces a migration that looks successful and has holes in it.

The Outcome: Every incident migrated, with effectively all of its notes, before the TOPdesk contract ended.

By the Numbers

• Notes migrated: over 450,000
• Attachments processed: roughly 247,000
• Attachments migrated: over 157,000
• Incidents migrated: roughly 109,000, of roughly 109,000 in scope
• Contacts: around 1,100
• Knowledge items: over 600
• Departments: close to 570
• Locations, branches, categories and statuses mapped: around 200
• Validation issues found before the first write: 95
• Data span: twelve years of service history

The Challenge: A Live Destination and a Fixed End Date

Minebea Intec builds industrial weighing and inspection equipment, and traces its business back more than 150 years. Its IT service desk had run on TOPdesk for twelve years, accumulating incidents across sites in Germany, wider Europe and Asia. The move to ManageEngine ServiceDesk Plus had a date attached that could not move: the day the TOPdesk contract expired.

Three constraints shaped everything.

• The destination was already in use. ManageEngine was not an empty tenant waiting to be filled. It was live production carrying real work for real technicians. Every call made against it during discovery was a read-only GET, and the operating rule for the whole project was that the migration would only ever write records it had created itself — never update or delete anything it had not.
• ManageEngine fails quietly on bad mappings. If a migrated ticket references a site, category or technician that does not exist in the destination, ManageEngine does not reject the request. It accepts it and drops the field. The ticket arrives, it looks fine, and the site is simply blank. At a hundred thousand tickets, that is not something anyone discovers by spot-checking.
• TOPdesk's API did not behave as documented. The incident list declared a response path that did not match the actual payload. Pagination had a maximum limit high enough to overwhelm the worker processing it. TOPdesk turned out to use three different pagination dialects across its endpoints, requiring per-method handling. Its query syntax and its archived flag are mutually exclusive, so filtering and reaching archived records could not be combined. There is no single display-name field on a person, so a name has to be assembled. And its status model is three fields rather than one. Anyone who has planned a TOPdesk data extraction will recognise most of that list.

Validating the Mapping Against the Live Destination

The migration checklist — the spreadsheet where the customer states how their old values map to new ones — came back completed. Rather than reading it into a configuration and running a sample, every destination value the customer had typed was checked against the live ManageEngine instance first.

That found 95 issues, in three groups.

Twenty-two sites did not exist. Sixty rows of the checklist mapped onto 22 distinct site names. None of them were present in ManageEngine, which held only five sites at the time and none matching. Left alone, every migrated ticket would have arrived with no site at all.

Four of eight categories were missing, and one of the four that did exist contained a double space in its name — so matching had to normalise whitespace or fail on a category that was genuinely there.

Only 14 of 33 agents resolved. Ten rows were marked for migration with no technician named. Nine had a TOPdesk email address pasted in, which never resolves, because ManageEngine uses a different address convention for the same people: where TOPdesk holds a technician's ordinary corporate address, ManageEngine holds an administrative variant of it. Pasting the source address resolves to nobody. The remainder were system and service accounts, and external consultants who could be created as non-login technicians at no licence cost so their historical assignments survived.

One finding is worth naming plainly, because the instinct is to record it as customer error. On three tabs the customer had typed their mapping into the notes column rather than the mapping column — a one-column shift. The dropdown was on the correct column, but nothing stopped them typing one cell to the right. That is a flaw in how the checklist was built, not a mistake by the person filling it in, and the fix was to read the notes column as a fallback rather than to send the sheet back and ask them to do it again.

The ClonePartner Solution: Fix the Integration, Then Move the Data

Integration first. Before any data moved, the TOPdesk integration itself was corrected: the incorrect response path, a pagination limit that was destabilising the worker, per-method handling for the three pagination dialects, and handling for the query-versus-archived conflict. On the ManageEngine side the OAuth scopes were too narrow to do the work; they were widened at the environment level, leaving the base integration untouched, and the account reconnected and verified.

Pull, then verify, then push. The full source pull ran to completion and was checked end to end against live TOPdesk before anything was written. Statuses, closure codes, priorities, impacts, urgencies, request types, operator groups, sites, categories, subcategories and technicians were all resolved from the validated checklist into the migration configuration, so a mapping change never required a code change.

Two platform limitations were designed around rather than hidden. ManageEngine does not allow a note's author or timestamp to be set, so every migrated note is prefixed with its original author and original time — the information survives in the text where it cannot survive in the metadata. Resolution and completion timestamps are read-only when a request is created, so they are preserved in a footer on the request description. Neither is as good as native fields. Both are better than losing twelve years of chronology, and both were disclosed rather than discovered.

Attachments were staged, sanitised and re-hosted. Inline images were re-hosted so they render in the destination, and content was sanitised for the web application firewall sitting in front of it.

What Did Not Migrate, and Why

Three gaps were identified before the bulk run and reported rather than absorbed.

Roughly 89,000 attachments were refused by the destination. ManageEngine ServiceDesk Plus caps a request at 50 attachments. Once a migrated ticket already held 50, every further file was rejected — by design, by the destination, and not recoverable from our side. The rejections were recorded individually with their reason, so the exact files are known rather than estimated. A handful were also over 10 MB.

A further set of attachments could not be served by TOPdesk at all. These return HTTP 500 on download, reproducibly, across runs hours apart. This is source-side and retrying does not fix it; a reclaim pass recovered a portion. A smaller number return 404 — TOPdesk lists the file but no longer holds it. Minebea were asked to spot-check a few of these in the TOPdesk interface themselves, because if they cannot download them there either, it is pre-existing data loss on their side and better acknowledged before the migration than discovered after it.

The audit progress trail was not migrated. The customer chose to exclude it, and queried their own decision while doing so, so it was confirmed rather than assumed.

The Results: Complete Before the Contract Ended

The push ran for four weeks, finishing five days before the TOPdesk contract expired.

Every incident in scope migrated — roughly 109,000 of roughly 109,000, a complete transfer — carrying effectively all of its notes. Attachments landed wherever ManageEngine's per-request cap allowed, with the remainder itemised. What Minebea has in ManageEngine is twelve years of service history, with the original chronology readable on every note and every closed request, in the system they will still have after the old one is switched off.

What Made This Migration Different

For teams planning an ITSM move into a live destination, three details from this project are worth noting:

• Validate the mapping against the destination, not against the spreadsheet. A checklist that is internally consistent can still be entirely wrong, because the only thing that matters is whether each value exists in the target system. Checking 95 values against live ManageEngine before the first write turned a class of silent, unrecoverable data loss into a list of things the customer could go and create. Doing that check after a sample would have meant re-running; doing it after the bulk load would have meant a hundred thousand tickets with blank sites.

• When a destination is production, read-only is the default until proven otherwise. Every discovery call here was a GET, and the standing rule was that the migration would only ever touch records it created. That constraint costs a little speed and removes an entire category of disaster — one where the damage is to data nobody was migrating.

• Disclose the platform's limits as findings, not as footnotes. ManageEngine will not let you set a note's author or a resolution timestamp, and it will not take more than 50 attachments on a request — constraints that outlive any one project and shape a ServiceDesk Plus migration in either direction. None of those are negotiable and none of them are visible in a project plan. Naming them early — with the workaround, and with the count of what it affects — turns them into decisions the customer makes with full information, rather than surprises they find in their new helpdesk three weeks after go-live.