Export data from ManageEngine ServiceDesk Plus

Export data from ServiceDesk Plus before the contract ends

A renewal, a licensing change or a data residency requirement is usually what starts an exit plan, and the first question is what you can take out of ServiceDesk Plus. Records, attachments and reports can usually be exported, while workflows, SLAs, templates and automation are normally rebuilt in the target system. Treat that split as the working assumption for planning, then verify it, because export options differ by edition and version. Start by listing every process the service desk runs, every report the business reads each month, and every automation that changes a ticket without a person touching it. Those three lists separate the data you can move from the configuration you will recreate.

ServiceDesk Plus offers three practical export paths, and each one needs confirming. The first is query reports exported to CSV, which suits tickets, requesters and asset records with their standard fields. The second is custom tabular reports, where you choose the columns and filters, which works better when you have a defined field list for the target. The third is direct database access, which applies to on-premises installs and needs the database account, schema and supported read method confirmed with ManageEngine before anyone runs a query. For your installed version and edition, confirm which paths are enabled, which fields each includes, how multi-value fields and attachments are delivered, and whether conversation history and ticket descriptions export in full. Test each path on a sample of closed tickets before you commit to a schedule.

Plan the cutover around what the exports cannot carry. Map every exported column to a field in the target, decide which closed tickets justify migration and which stay in a read-only archive, and record how attachments arrive so they can be linked back to their tickets. Ask your ManageEngine account team in writing which export rights, database access terms and modules your contract covers, since a licensing change can alter what you are permitted to extract. Rebuild workflows, SLAs, templates and automation from a written inventory in the target, and test each one against a sample ticket. The rebuild is largely a one-time cost, while keeping the archive for audit lookups recurs as storage and access work.

Which ServiceDesk Plus data you can export, and how

This table lists each data type you will need to move out of ServiceDesk Plus, the export method we would expect to work for it, the format, and the limits to confirm. Cells marked as a confirmation item have not been verified against ManageEngine's current documentation for your edition and version, so check them on a sample before relying on them. Treat the table as a plan for testing, not as a guarantee of completeness.

Data type	Export method	Format	Known limits and confirmation items
Requests	Query report exported to CSV	CSV	Confirm whether the export includes request descriptions, resolutions and custom fields, and whether it honors your filters.
Request history and notes	Custom tabular report or direct database read	CSV or database rows	Confirm: history and notes are often stored in related tables, so a flat CSV may not capture them in full.
Assets	Query report exported to CSV	CSV	Confirm which asset fields, relationships and asset states are included, and how software and component records are exported.
Users and technicians	Query report exported to CSV	CSV	Confirm that passwords are not exported and that technician roles, groups and site assignments are captured in the export.
Departments	Query report exported to CSV or direct database read	CSV or database rows	Confirm how parent and child department hierarchies appear in a flat export.
Categories	Query report or configuration review	CSV or manual list	Confirm: category trees and linked templates may need to be recorded by hand, since they are configuration rather than records.
Attachments	Export from the request record, or copy the attachment store on on-premises installs	Original files	Confirm: CSV exports carry file references, not file contents, so attachments usually need a separate copy step.
Knowledge base articles	Custom tabular report or direct database read	CSV or database rows	Confirm whether article body text, attachments and approval status survive the export in usable form.

What usually does not leave as data, and how to handle each item

Query reports and tabular exports move records, but the configuration that makes ServiceDesk Plus behave like your service desk usually stays behind. The cards below cover the items teams most often rebuild by hand, with a workaround and an owner for each. Confirm every export limit and file format in your own edition and version before you plan the cutover.

Workflows and automation rules

Workflows and automation rules decide how requests are routed, updated and escalated when conditions are met. They are logic, not records, so a CSV or database extract captures the outcomes of past automation but not the rules that produced them. Document each rule from the admin screens, including triggers, conditions and actions, and export a sample of triggered requests so you can confirm the behavior you need. The service desk lead should own the rebuild, with a platform engineer validating each rule in GLPI or iTop against test tickets.

SLA definitions and escalation logic

SLA targets, business hours, holidays and escalation steps are configuration objects that tie priorities and due times to a calendar. Exported ticket dates show whether a target was met, but they do not show the target definition itself. Record each SLA with its response and resolution targets, calendar, priority mapping and escalation chain, then reproduce it in GLPI or iTop and replay a sample of closed tickets to compare breach flags. The ITSM process owner should sign off on the results, since historical SLA reporting depends on it.

Request templates and forms

Request templates store the fields, default values, categories and instructions that agents and requesters see when they open a ticket. A ticket export carries the field values that were filled in, but not the form layout or the rules that populated them. Capture each template screen by screen, note which fields are mandatory and which are hidden by category, and export a few sample requests to show the data shape. The service desk team should own this item, because requesters feel template changes first.

Approval chains

Approval chains define who must approve a request, in what order, and what happens on rejection or timeout. Approval decisions appear in the request history, but the chain definition that governs future requests does not travel with the data. Write down each chain with its approvers, thresholds and delegation rules, and confirm with the approvers that the chain still matches current policy before you rebuild it. The change or access manager should own this item, since approvals often map to a control in the team's own change process.

Notification rules and email templates

Notification rules control who receives an email or alert for each status change, and the templates control what the message says. Mail that was sent is not an export of the rules, and templates often include branded text and links that must be checked for the new platform. List every rule with its trigger, recipients and template, remove stale recipients, and test each one on a non-production instance with a mail capture tool. The service desk administrator should own this, with a security reviewer checking that no notification exposes data to the wrong audience.

Custom roles and permissions

Custom roles and permissions decide which technicians can see, edit, close or reassign which requests and assets. Account user lists may export, but the role matrix and its scope settings usually do not map one to one onto GLPI profiles or iTop profiles. Export the user list and role assignments where your edition allows it, then build a permission matrix that maps each ServiceDesk Plus role to target profiles and test it with a representative account from each group. The identity or security lead should own this item, because a permission gap during cutover is an access control issue, not only an admin inconvenience.

The sequence for a complete export, with verification at each stage

This sequence turns an export from a one-off download into a verified, archived copy of your ServiceDesk Plus data that you can check against the source before any cutover decision is made.

Inventory data types and the environment
The service desk owner lists every data type to leave the system: requests with their notes and attachments, problems, changes, assets, components, software licenses, contracts, users, technicians, groups, vendors, and the knowledge base. For each type, record where it lives (cloud or on-premises), the approximate record count shown in the product, and which fields matter to downstream teams. Confirm whether you run the cloud edition or an on-premises install, because that determines whether database access is possible. The output is a signed data inventory that the owner and the platform team both accept before any export runs.
Confirm export rights and database access
The ServiceDesk Plus administrator confirms that the export account can run query reports, schedule or download CSV output, and see every module in scope, since a technician role may hide records. On on-premises installs, the database administrator confirms whether read access to the backing database is available and under what change-control approval. Ask ManageEngine, in writing, which data is reachable only through the UI or API and whether any export limits apply in your edition. The output is a short access record listing who holds each right and what remains blocked.
Export a small sample from each report
The administrator runs each query report on a narrow date range or a limited set of records, exports to CSV, and opens the file in a spreadsheet and a text editor. The check is that every expected column is present, character encoding survives accented names and multi-line descriptions, and dates and currency values are not silently reformatted. Note any field that appears only as a display label rather than a stored value, because it may need a lookup table later. The output is a sample set per data type with a list of fields that failed the check.
Check field mappings against the target model
The migration lead places each sample column next to the target data model in the destination platform, such as GLPI or iTop, and maps every source field to a destination field, a lookup, or an explicit drop decision. Pay particular attention to statuses, priorities, categories, urgency and impact values, which rarely match one to one, and to relationships between requests and assets. The check is a mapping sheet where every source column has a status and a named owner for each unresolved decision. The output is an approved mapping document that governs the full export.
Run the full export into a staging area
The administrator runs the complete set of exports into a restricted staging location that is separate from production and from the destination system. Each file is named by data type and export date, and the export job logs are kept with it. Confirm that any scheduled or emailed export completes and that large files are not truncated by a download limit. The output is a complete raw export set in staging, with logs showing that every job finished without error.
Verify record counts and spot-check links
The migration lead compares the row count of each CSV, minus header lines, with the count reported by the source for the same filter, and investigates any difference before proceeding. Then a second reviewer picks a random sample of requests and checks that the attachments referenced exist, the linked assets and requesters match the source screen, and the resolution notes are intact. The check is a reconciliation table showing source count, exported count and sampled matches for each data type. The output is a signed reconciliation that either clears the set or lists exceptions with owners.
Document what must be rebuilt by hand
The service desk owner records the items that CSV and database exports do not carry in usable form, typically workflows, SLA rules and escalations, request and change templates, automation rules, notification rules, and custom form layouts. For each item, the owner notes its current behavior, who depends on it, and whether it will be rebuilt or retired in the destination. Ask the destination vendor or partner which of these it can import and which require manual configuration. The output is a rebuild register that the business signs off before cutover planning starts.
Archive the raw export with checksums and a manifest
Once reconciliation clears, the platform team moves the raw files into the archive store, computes a checksum for every file, and writes a dated manifest listing each file, its checksum, the source system version, the export date, the reconciliation result and the people who approved it. The archive is kept read-only and restored once to confirm it opens. The check is that the checksums in the manifest match the archived files on a second computation. The output is a verifiable archive that stands as the evidence base for the migration.

On-premises database access versus cloud exports

On an on-premises ServiceDesk Plus installation, your organization may have a database under its own control, which can make bulk extraction faster than report exports. That access should not be assumed. Confirm with ManageEngine which database engine and version your build uses, whether a read-only or reporting route is documented for your edition, and whether using it affects your support entitlement. Ask for the route in writing so that your extraction method is one the vendor has accepted.

Confirm the documented route: Ask ManageEngine whether direct reads are supported, which accounts may be used, and which views or tables they cover. Do not assume any particular table or endpoint exists.
Ask about support impact: Get a written answer on whether ad hoc queries against the database void or complicate support for an incident.
Respect locking and load: Long-running reads on a production database can contend with the application. Schedule extractions outside busy periods and test on a copy first.
Plan for schema change: Upgrades can change internal structures, so a script that works today may break after the next release. Record the build version alongside every extract.
Verify the output: Compare row counts and sample records against the application's own reports before you trust the extract.

Before running any query, make sure you have a recent backup and a written confirmation of the supported access route.

Rebuilding automation and proving the export is complete

Treat the export as complete only when the target holds the same records, counts and rules you exported from ServiceDesk Plus, and every difference is written down with a decision. Start by mapping the source vocabulary to the target. Request categories, priorities, statuses and technician groups in ServiceDesk Plus rarely line up one to one with GLPI or iTop, so build a mapping table with one row per source value, the target value it becomes, and the owner who approved it. Where a ServiceDesk Plus status has no direct equivalent, record the chosen substitute and the reason. Do not let the mapping live only in someone's head or in a migration script comment.

Rebuilt SLA and escalation rules are where most cutovers go wrong, because ServiceDesk Plus automation (workflows, escalations, notifications and templates) is usually not carried by a CSV export. Rebuild each rule from the written policy, not from memory of the old configuration, then test it against sample tickets that you create in a non-production instance. Each test case should state the input, the expected due date, escalation and notification, and the observed result. In GLPI, check how the SLA and OLA definitions attach to tickets; in iTop, check the SLA and escalation settings it documents. Confirm both against the current vendor documentation in your own environment, since configuration options differ by version.

Keep a reconciliation sheet that records, for each object type, the count in the export, the count imported, the count rejected and the reason for each rejection. Log every exception and every decision that changed a value, with the approver and date. For data checks, GLPI's asset documentation describes how assets and their relations are represented, which helps you verify that imported inventory is linked correctly. iTop offers CSV import and data consistency audits that can flag broken references in the CMDB. These checks must run in your own environment against your own data, and the sheet should be signed off by the service owner before ServiceDesk Plus is switched off.

What to plan before the ServiceDesk Plus renewal or termination

Leaving ServiceDesk Plus is easier when the team settles the contract and data questions before the notice deadline. The cards below cover the items that decide whether an export is complete, usable and defensible. Contract terms must be confirmed against the signed agreement, not against this page or a vendor's general documentation.

Does access continue after the end date?

Confirm the license end date and whether read access, report export or database access continues after it. If access stops on the end date, every query report, attachment and history view must be exported before then. Ask the vendor in writing whether a read-only grace period exists and how long it lasts, and record the answer alongside the signed agreement.

Which exports need vendor action?

Check whether your edition lets administrators run full exports directly or whether some datasets require a support request or a vendor-enabled feature. Test each export type on a copy of the data, including attachments, closed requests and asset relationships. Gaps found now are cheaper to close than gaps found after access ends.

How long to keep the raw export?

Decide how long the raw CSV files, database dumps and attachment archives must be retained, and who owns that archive after the migration. Your retention schedule may come from internal policy, audit requirements or sector rules, so confirm them with compliance before deleting anything. Store the archive with restricted access, since tickets often contain personal data.

How long is the parallel run?

Plan a window in which ServiceDesk Plus stays available and read-only for reference while the new platform takes live tickets. Agree on who may consult the old system, for which questions, and when it is switched off. Set the window length from your ticket volume and open backlog, and confirm that the vendor permits read-only use during that period.

What configuration must be documented?

Workflows, SLAs, escalation rules, request templates, custom fields and automation rules usually do not come out as data. Record each one with its purpose, owner and trigger while administrators can still view it. Without this record, the new platform is configured from memory, and behavior that staff rely on quietly disappears.

What happens to our data at exit?

Ask the vendor to confirm in writing how your data is returned or deleted at the end of the contract, in what format, within what period and with what certificate or confirmation. Clarify whether backups held by the vendor are also deleted and when. Record the response in the contract file before the notice deadline.

How much effort and expertise does a ServiceDesk Plus export take?

Can our own team export ServiceDesk Plus data without outside help?

Often yes for the core records, but the export is the easy part. Query reports can be run and exported to CSV by a administrator who knows the console, and on-premises installs may allow direct database access for a fuller extract. The harder work is deciding what to keep, mapping fields to GLPI or iTop, and rebuilding workflows, SLAs, templates and automation by hand. A team with an administrator, a database-aware engineer and time for testing can do much of this internally. Confirm your edition's export options and your own admin rights before you plan the split of work.

How does the number of requests and assets change the effort?

Volume mainly affects the extract, the import and the validation, not the design work. More requests and assets mean longer exports, more import batches and more records to reconcile between source and target. History depth matters too, since closed requests with long comment threads take more care to map than simple asset lists. Ask for a record count per object type (requests, assets, users, attachments) before scoping, because that count is what most quotes are built on.

Does on-premises database access change the scope of the work?

Yes, it usually widens the options and the care required. Direct database access on an on-premises install can give complete, consistent extracts, including fields that query reports do not expose. It also means working with schema details, custom fields and attachment storage, and avoiding changes to a production database. Cloud deployments generally limit you to the reports and exports the console offers. Confirm with ManageEngine which access your deployment includes and whether the vendor's terms allow you to read the database for migration.

What must our team provide before a migration starts?

Three things decide whether the work stays on schedule:

Administrator access to ServiceDesk Plus and, where relevant, read access to the database or a service account for exports.
A sample of real records, including closed requests, assets with relationships and users from each group, so the mapping is tested on actual data rather than a demo.
A named owner for the rebuild of workflows, SLAs, templates and automation, who can decide which rules still matter and approve the target design.

Without the owner, rebuild decisions tend to stall in review.

How long should we plan for a parallel run?

Plan the parallel run around your change calendar and your reporting cycles rather than a fixed number of weeks. During the run, both systems stay available, new requests are checked in both, and the team compares counts, open items, SLA clocks and asset data for a period that covers at least one full reporting cycle, such as a month-end. The length depends on how many teams depend on the old reports and how many automations need proving. Agree the exit criteria in writing before the run starts.

What does fixed-scope work cover compared with ongoing support?

A fixed-scope engagement covers a defined set of deliverables, such as the export plan, the data mapping, the import into a named target, validation and cutover support, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support is a separate retainer for upgrades, updates, continuous testing and operational help after go-live. Ask for the scope in writing, the exclusions (for example, custom integrations or extra report types) and what happens if the record count differs from the estimate. DeployOpen does not publish a price list, so a quote follows from the written scope.

Which cost components should we ask about in a quote?

Ask for each component separately so you can see what is one-time and what recurs:

Discovery and export planning, including the review of your reports and database access.
Data mapping and transformation for requests, assets, users and attachments.
Rebuild of workflows, SLAs, templates and automation on the target.
Test imports, validation and the parallel run.
Cutover and post-go-live support, separate from any retainer.

Cost rises with the number of custom workflows and integrations, and falls when the team has already documented its rules and cleaned its data.

Who is responsible for data quality during the export?

The customer owns the decision about which data is correct and worth moving, and the implementation partner owns the mechanics of extracting, mapping and checking it. Stale users, duplicate assets and abandoned categories should be cleaned or archived before the final extract, because migrating them unchanged carries the old problems into the new system. Agree who signs off each record type and how exceptions are logged. Independent audit reports are issued by auditors, not by the implementation team, so keep your own evidence of the reconciliation.

How DeployOpen scopes and delivers an export and exit

DeployOpen treats the export from ManageEngine ServiceDesk Plus as a defined piece of work with written scope, not a one-off script. We inventory what can be extracted, agree what gets rebuilt in the target platform, and hand over documented evidence of what moved and what did not.

How we scope

We inventory the request, asset, user and report data your ServiceDesk Plus instance holds before any export begins.
We confirm which export paths your edition and deployment expose, including query reports, custom reports and database access.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

We build extraction queries and mapping files that carry requests, assets and users into the target platform's import formats.
We rebuild categories, SLAs, workflows, templates and automation in the new platform from documented specifications.
We test imports on a copy of the data and reconcile record counts and sample records against the source system.

How we hand over

We deliver a runbook covering the export steps, field mappings, known gaps and the order of cutover tasks.
We document every item that was rebuilt by hand, so your team knows which configurations changed during the move.
We keep an export archive and reconciliation report so you can show what was moved and when, if an auditor asks.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after cutover.
We can help your team validate the first weeks of live data in the new platform against the archived source extract.
Ask for the written scope to name who owns the source system access, the archive retention and the sign-off steps.

How to export your data from ManageEngine ServiceDesk Plus