Minebea Intec

TL;DR

Customer: Minebea Intec — industrial weighing and inspection technology, headquartered in Hamburg, part of the MinebeaMitsumi group, with sites across Europe and Asia.

The move: TOPdesk to ManageEngine ServiceDesk Plus Cloud, EU data centre. Incidents including the archived ones, their notes and their attachments.

The scope: Roughly 107,000 incidents, over 350,000 notes and close to 130,000 attachments, spanning August 2014 to August 2026.

The constraint: The destination was not an empty tenant. It was a live ManageEngine instance already carrying real work for real technicians, and the TOPdesk contract had a fixed end date.

The outcome: Every in-scope incident in ManageEngine, oldest first, finished two days before the contract ended — and an offline archive of everything TOPdesk held, so the old system could be switched off with nothing left behind in it.

The challenge

Minebea Intec's IT service desk had run on TOPdesk for twelve years. Moving to ManageEngine ServiceDesk Plus had a date attached that could not move: the day the TOPdesk contract expired. Two things made that harder than a date on a plan suggests.

The destination was already in use. ManageEngine was live production, carrying work for technicians who would be in it the next morning. There was no sandbox to be wrong in.

ManageEngine fails quietly. If a migrated ticket names a site, category or technician that does not exist in the destination, ManageEngine does not reject it. It accepts the request and drops the field. The ticket arrives, it looks correct, and the field is blank. At a hundred thousand tickets, nobody finds that by opening a few and checking.

What we did

Proved the mapping against the live system before writing anything. A mapping checklist is agreed on paper, but the only thing that decides whether a value lands is whether ManageEngine already holds it — and ManageEngine drops an unknown value rather than refusing it. So every destination value was checked against the live option lists and put in place there before the first record was written — sites, categories and technician records alike. The bulk run started against an instance that already held everything the migration was going to reference.

Treated the live instance as read-only until proven otherwise. Every discovery call was a GET. The standing rule for the whole project was that the migration would only ever write records it had created itself — never update, never delete anything it had not. That costs a little speed and removes the category of disaster where the damage lands on data nobody was migrating.

Ran the migration oldest first, in one pass. History was written in the order it happened, serially and date-sorted, so a technician opening a ticket in ManageEngine reads it the way it unfolded. The bulk run took 71 hours of continuous writing across tickets, notes and attachments.

Verified by reading ManageEngine back. The ticket figure comes from querying the destination for every record carrying the migration tag and counting what came back. A destination read is the only count that can be checked by anyone else, which is why it is the one on this page.

The result

Every in-scope incident migrated — 100%, confirmed against the live instance — carrying 99.8% of their notes and 99.8% of their attachments. The remainder were notes that were already empty in TOPdesk, and attachments that TOPdesk itself could no longer serve or that sat past ManageEngine's size ceiling. Every one was itemised by name, size and date and handed over.

Then the parts that are easy to leave out of a plan. A delta pass carried across everything that changed in TOPdesk while the migration ran. The knowledge base followed — 792 solutions across English, German and French, each verified against the destination. And on 25 September the whole of TOPdesk was delivered as an offline archive: every ticket, note, attachment and knowledge article, 25.6 GB across nine files, with a viewer that opens in a browser with no account and no internet connection and searches the full text of twelve years of tickets.

The migration finished on 28 September. The TOPdesk contract ended on the 30th.

Under the hood

The technical detail, for anyone planning the same move.

What TOPdesk's API does that its documentation does not mention

• The incident list returns a bare array, not the wrapped object the rest of the API returns.
• Three different pagination dialects across endpoints. Incidents use one, the operator family uses another, and several reference lists ignore the offset entirely and return whatever fits in a single page. Apply one dialect everywhere and an operator list comes back as 10 rows of 36 — a clean HTTP 200, no error.
• query and archived are mutually exclusive. You can filter, or you can reach archived records, but not both. Since four-fifths of this history was archived, the bulk pull had to be a full walk.
• The default sort is newest-first. Offset-paging a multi-hour walk against a live system means every ticket created while you page shifts the window down by one, and records are skipped silently. Sorting ascending by creation date holds the window steady, and unlike query it is compatible with the archived flag.
• The display-name field is not always name. Operator groups use groupName, operators use dynamicName, and name comes back undefined on both.
• The status model is several fields, not one. Whether a ticket is closed, which support tier handled it, and its processing state are three separate things, and the processing state is populated on a minority of records.
• TOPdesk returns 500 on some of its own stored attachment bytes. The metadata is correct, the byte size is correct, and the download errors — reproducibly, across runs hours apart. That is source-side, and no amount of retrying fixes it.

What ManageEngine ServiceDesk Plus requires

• Writes are form-encoded input_data. The identical payload sent as a JSON body returns 400.
• A terminal status needs its resolution on the same call. Setting a request to Resolved without resolution content returns HTTP 200 and leaves it Open. Sending the resolution on the create call is what makes it stick. The alternative is an update call per ticket, which at the published limit is about sixty hours of runtime on a corpus this size.
• Note author and timestamp cannot be set. Every migrated note is attributed to the migrating account and stamped with the import time, so the original author and original time are written into the note's first line instead. Resolution and completion timestamps are read-only on create and are preserved in a footer on the request description.
• Fifty attachments and fifty megabytes per request, 25 MB per file. Once a ticket is at that cap, nothing further can be added to it.
• Subjects are fragile. ServiceDesk Plus rejects a subject containing < followed by a non-space character, and silently truncates a subject at its first emoji — returning 200 and a real request id while the text after it is gone. The same truncation applies to knowledge-base topic and solution titles, which is a four-byte UTF-8 storage limit rather than a validation rule.
• Unknown values are dropped, not refused — the behaviour that makes validating the mapping against the live instance non-optional.
• Published rate limits, with a five-minute lock on breach: 15 creates per 10 seconds, 30 updates per minute, 60 reads per minute. Retrying on a 429 simply trips the lock again, so pacing has to be proactive rather than reactive.
• Business rules, notification rules and SLA policies are not exposed by the REST API at all. They are admin-UI configuration, so there is no API route to record the current state before an import or restore it afterwards.

What did not come across, and where it went instead

Three things could not migrate. All three were identified and reported before the bulk run.

Notes with no body. A few hundred notes in TOPdesk contain no text at all. There was nothing to write.

Attachments TOPdesk could not serve. A small number return 404 or 500 on download, reproducibly. A sample was opened in TOPdesk's own interface to confirm the files were already unreadable at source, and the full list went over with the ticket each one belongs to.

Older files on tickets already at ManageEngine's cap. A long tail of attachments on a small number of very long-running tickets, nearly three quarters of them produced by four automated senders — monitoring alerts, scan-to-email and the like — rather than anything a person wrote. They are all in the offline archive, with the ticket they belong to.

That is what the archive is for. It is not a backup of the migration; it is the answer to "what about everything with no home in the new system" — the knowledge base, the TOPdesk-native fields with no ManageEngine equivalent, the original note authorship as structured data, and every attachment, including the ones the destination would not take. Each ticket in it carries both its TOPdesk link and its ServiceDesk Plus link, so the archive joins to the live system rather than sitting beside it.

What made this migration different

For teams planning an ITSM move into a destination that is already in use:

• Validate the mapping against the destination, not against the spreadsheet. A checklist can be internally consistent and still not resolve, because the only thing that decides is whether each value already exists in the target. Checking before the first write turns a class of silent, unrecoverable loss into a list of things to create. Leave it until after the bulk load and it is a hundred thousand tickets carrying blank fields, with nothing in any log to say so.

• When the destination is production, read-only is the default until proven otherwise. Every discovery call a GET, and a standing rule that the migration touches only what it created. A constraint that costs a little and removes an entire class of outcome.

• Name the platform's limits as findings, with the count of what they affect. ManageEngine will not let you set a note's author or a resolution timestamp, and it will not take more than fifty attachments on a request — constraints that outlive any one project and shape a ServiceDesk Plus migration in either direction. None are negotiable and none appear in a project plan. Raising them early, with the workaround and the number of records involved, turns them into decisions the customer makes with full information, before go-live rather than after it.

• Plan for what has no home in the new system. Most of a migration is the records that map cleanly. The part a customer remembers is what happened to the rest — and an archive they can open without us, search without us and keep after the old contract lapses is a better answer than a list of things that did not fit. Anyone scoping a TOPdesk data extraction should decide early whether that archive exists, because it is far harder to produce once the source is switched off.