How to export your data from ServiceNow

Export your data from ServiceNow before the contract ends

List exports and scheduled export sets can take ITSM record data out of ServiceNow, but attachments need a separate REST extraction, and workflows and configuration do not travel as data. Teams facing a renewal, a licensing change or a data residency requirement need this answer early, because the export becomes the only copy of their incident, problem, change and asset history that they control. This page covers documented export paths only, not undocumented database access or vendor-assisted extraction.

From a list view, ServiceNow exports records to CSV, Excel, XML and JSON, but each export is subject to a default record limit. Confirm that limit on your release and plan batched exports for large tables such as incidents and configuration items. Export sets go further: they write records from the instance to a file on a MID Server, with the target format and file path set in the export set, and they can run on a schedule. Scheduled exports are useful for repeated snapshots before cutover, but someone must confirm that the MID Server is available, has network access to the target path and is covered by your support arrangements. Create an export set in the product documentation sets out the options.

Export sets do not include file attachments. Attachments must be pulled separately through the REST APIs or outbound REST messages, so budget an extraction step that keeps each file linked to its parent record. Configuration is a separate exercise: workflows, business rules, catalog items, SLA definitions and notifications are not exported as record data, so document them before the contract ends. Before you rely on any path, run a test export of one table, compare row counts with the list view, check a sample of attachments and store a dated copy with its schema. Ask your ServiceNow account team which fields and formats it supports for your release.

Which ServiceNow data you can export and in which formats

This table lists the three ways to take ServiceNow records out and what each one leaves behind. List exports are quick but bounded, export sets run to a MID Server on a schedule, and attachments need their own REST extraction. Use it to plan which exports to build before you choose a target platform.

Export route	What it gives you	What to confirm in your release
List export (CSV, Excel, XML, JSON)	Downloads records from a list view in the chosen format, suited to smaller, ad hoc pulls	Default record limit for each format, since the limit decides whether a full table can be pulled this way
Scheduled export set	Writes records from the instance to a file on a MID Server, with the target format and file path set in the export set and an option to repeat on a schedule	MID Server availability, write access to the file path and which target formats your release offers
Attachments	Not included in export sets, so they must be moved separately through REST APIs or outbound REST messages	Who builds the REST extraction, how attachment records link back to parent records and total attachment storage
Incident, problem, change, configuration item, asset and knowledge	Export sets work on records from instance tables, but the documentation does not list each of these tables individually	Field names, reference fields and relationships for each table in your instance, and whether any custom tables need the same treatment

What ServiceNow export sets leave behind

An export set moves records from a ServiceNow instance to a file, but it is not a full copy of the platform. Attachments, workflows, scripts, catalog definitions, dashboards and integrations each need their own inventory and a separate path before the instance is switched off.

File attachments need REST extraction

Export sets do not include file attachments. Pull them separately through the documented REST APIs or with outbound REST messages, matching each file back to its parent record by sys_id. Confirm that every attachment's size, content type and file name survive the transfer, and check the record counts against the source table before you delete anything.

Workflows and flow logic

Workflows, flow designer actions and business rules encode how incidents move between groups, approvals and states. Export sets carry the resulting records, not the logic that produced them. Document each active flow, its trigger and its approval steps, then rebuild the equivalent routing in GLPI or the chosen tool by hand.

Custom scripts and business rules

Script includes, client scripts and business rules often hold field defaults, validation and assignment logic that users never see. None of this travels in an export. Inventory every custom script by table and trigger, then decide per script whether it is still needed, can be replaced by a native GLPI feature, or must be written as a small external job.

Service catalog definitions

Catalog items, variables, order guides and their approval rules are configuration, not records. Export the catalog as a list for reference, but expect to recreate each request form manually. Map every catalog item to a GLPI ticket template or form, and confirm who approves each request type before go-live.

Dashboards and reports

Performance Analytics dashboards, homepage layouts and scheduled reports stay in ServiceNow. Export the underlying data sets to CSV, then rebuild the views that leaders depend on in the target reporting tool. Agree the list of reports that must match the old numbers, because definitions such as SLA breach or reopen rate may differ.

Integrations and inbound endpoints

Monitoring alerts, email inbound actions, SSO and REST integrations point at ServiceNow endpoints. Each one must be found, repointed or retired. Build a list from integration logs and the instance's REST message and inbound email records, then test each feed against the new system before the cutover date.

How scheduled export sets to a MID Server work

A ServiceNow export set writes records from the instance to a file on a MID Server, the on-premises agent that sits between the instance and your network. You choose the target format and the file path inside the export set itself, and you can schedule the export to repeat. That makes it the mechanism for a bulk, repeatable copy of table data rather than a one-off download from a list view. Keep in mind that export sets carry records only. File attachments are not included, so attachment handling needs its own plan, covered elsewhere on this page.

Before you build the export set, confirm that the MID Server can write to the target path. The server needs network and file system permissions on that location, and the path must survive the server's own maintenance and patching cycle. Next, create a dedicated service account with read access to every table you intend to export, and test it against the tables that hold the largest volumes. Access gaps usually show up as partial files, so verify row counts against the instance before you trust an export. Check the MID Server and export set configuration against the current ServiceNow documentation for your release, since options and field names vary by version.

Plan the schedule around your cutover date. A recurring export lets you capture changes made after the first full extract, such as new incidents, closed changes and edited configuration items, so the final load into the new platform is a delta rather than a full re-run. Decide how many runs you keep, where the files are archived, and who signs off that the last export covers the cutover window. Ask ServiceNow or your partner to confirm how the export set behaves during instance upgrades and MID Server restarts, because a missed run near cutover is the easiest gap to overlook.

The export sequence and how to verify each stage

This sequence moves ServiceNow records and attachments out in a deliberate order, so each stage has a check that proves it worked before the next one starts. The output is a complete, counted and spot-checked export that a migration team can trust before loading anything into a new system.

Inventory tables and attachments in scope
The ITSM owner and a ServiceNow platform administrator list every table that holds records you need, such as incidents, problems, changes, configuration items, assets, contracts and knowledge articles, and note which fields and related lists matter. Separately, they identify which tables carry file attachments, since export sets do not carry those files. The output is a signed-off inventory with an expected record count per table, taken from the instance's list views. Confirm the counts with the business owner of each table before moving on, because every later check compares against these numbers.
Configure export sets and the MID Server path
A ServiceNow administrator creates an export set for each table group, choosing the target format and the file path on the MID Server that will write the output. Where the export must repeat, the export set can be scheduled as a recurring export. Confirm with your ServiceNow team that the MID Server is healthy, has write access to the chosen path and has enough free disk space for the expected output. The check is a small test file written to that path, opened and read back, with its size and field headers matching what the export set specifies.
Run a test export on a sub-instance or small slice
Before the full run, export a limited slice, either on a non-production sub-instance or on a small date range of records in production. The migration engineer compares the test output against the instance: the row count for the slice should match a filtered list count in ServiceNow, required fields should be populated, and date and reference fields should keep their values. Spot-check at least one record per table by opening the source record and the exported row side by side. Log every mismatch, fix the export set or the field selection, and repeat the test until the slice matches cleanly.
Extract attachments through the REST API
Because export sets exclude attachments, a developer writes a script or outbound integration that calls the ServiceNow REST API to download each attachment and saves it to a storage location with its original name, its parent table and its parent record identifier. The developer records a manifest with one line per file, including the file size and a checksum. The check is that the manifest count matches the attachment count from the attachment table, that each file's size matches its manifest entry, and that a sample of files opens correctly in its native application and clearly belongs to the parent record it is linked to.
Freeze or track changes before the final run
Decide how to handle records that change during the migration window. Some teams pause write access for the tables in scope, while others export a final delta and track changes by update timestamp. The ITSM owner signs off the cutover approach in writing, and the administrator records the time the freeze starts. The check is a before and after count for the tables in scope, taken immediately before the final export, so any record created or changed after the freeze can be identified and explained.
Run the full export and reconcile counts
Run the full export sets on the MID Server and the full attachment extraction, using the same configuration that passed the test. Store the output in a dedicated location with access limited to the migration team. Reconcile each table: the exported row count should equal the source count taken at the freeze, and the attachment manifest should equal the attachment count for the same records. Compare file sizes and checksums for the stored output against the values recorded at creation. The stage closes when every table and attachment set reconciles, and any difference has a written explanation signed by the ITSM owner.
Verify parent links and archive the evidence
Confirm that exported records and attachments still point to each other, for example by checking that a sample of incidents with attachments resolves to the correct files and that cross-table references such as caller, assignment group and configuration item carry through as identifiers. Then archive the export sets, the attachment manifest, the reconciliation report and the sign-off record in a location your compliance team controls. The output is a verified dataset and an evidence pack that the next stage, loading into the target system, can rely on.

Export paths for cloud and customer-operated instances

On a ServiceNow cloud instance, your export options are the ones ServiceNow documents for the product. Teams typically combine list exports for smaller data sets, scheduled export sets for recurring bulk extracts and REST calls for attachments. ServiceNow operates the database tier in its cloud, so direct database reads are outside this path and should not be planned as a standard step.

List exports: Records can be exported to CSV, Excel, XML and JSON from list views, but each format has default record limits. Confirm the limits for your release before planning a bulk pull.
Scheduled export sets: An export set writes records to a file on a MID Server, with the target format and file path chosen in the set. You can schedule recurring exports from the same configuration.
Attachments: Export sets do not include file attachments, so plan a separate REST extraction and measure the attachment volume before you start.
Roles and MID Server access: Confirm which roles may create export sets, run MID Server jobs and read the output files in your instance.

Confirm the export limits and MID Server setup for your release with your ServiceNow account team before running a full test extraction.

What to plan before renewal or termination

ServiceNow's export tools move records out, but the surrounding decisions decide whether the exit holds. Each card below is a decision to settle with your own team, your legal function and your target platform before the contract end date.

Set the export test window

Schedule at least one full test export well before the contract ends, using the same export format and file path you will use at cutover. Record row counts per table, attachment counts and any export that hit a record limit. A test run in the final week leaves no time to fix a failed extract. Confirm with your ServiceNow account team which export options your subscription and instance configuration allow.

Map attachments to a separate extraction

Attachments are not in export sets. Decide early who will write the REST extraction for attachment files, how file names link back to parent records, and where the files will land. Budget that work as its own task with its own test, because it does not finish when the record export finishes.

Define retention and deletion for extracts

Exported files contain personal data, incident narratives and possibly credentials pasted into tickets. Agree in writing how long copies are kept, where they are stored, who can read them and when they are deleted after the target system is live. Confirm with your data protection or legal team that the retention rule matches your policy and any contractual obligations.

Name who approves each extract

Assign one owner per data set (incidents, problems, changes, configuration items, attachments) who signs off that the export is complete and accurate. Without named approvers, a missing table can pass unnoticed until users report gaps. Keep the approval record with the extract so an auditor or your legal team can trace what left the platform and when.

Confirm the target system is ready

Check that the destination, such as a self-hosted GLPI instance, has its hosting, database, backups, authentication and user accounts in place before the source is switched off. Ask the vendor or implementation partner to confirm which versions and prerequisites they support in your environment. Load a sample of records and verify field mapping before the full import.

Plan parallel running and the cutover

Decide how long both systems will run side by side, which system is authoritative for new tickets during that period and how changes made in one are carried to the other. Parallel running adds cost and staff effort, so put the period in the project plan. Document the final delta export and the date after which ServiceNow becomes read only.

Write the data return terms into the contract

Review your ServiceNow agreement for notice periods, the format and timing of data return, any fees for extraction assistance and what happens to data after termination. Get these terms confirmed in writing before you plan the export. Confirm the exact notice period and data return terms in your own agreement, since they vary by contract and this page does not set them.

Questions buyers ask before exporting ServiceNow data

Can our own admins export ServiceNow data without a partner?

Yes, for list exports and export sets, a ServiceNow administrator with the right roles can run them, but the work is more than clicking export. List exports to CSV, Excel, XML and JSON are built for smaller result sets, so large tables need scheduled export sets written to a MID Server, which means an admin must configure the target format, file path and recurrence. Your team should confirm which roles its administrators hold, whether a MID Server is already in place, and whether the export sets it needs are permitted by its change process before starting.

What makes a ServiceNow export harder than expected?

Three factors drive most of the effort: data volume, attachments and custom tables. Large instances with years of incident, change and CMDB history take longer to extract and validate than small ones. Export sets do not include file attachments, so attachments need a separate extraction through REST APIs or outbound REST messages, which is a development task in its own right. Custom tables, scripted fields and integrations that write to the instance each add mapping work, because their meaning is rarely documented in the export itself.

How long will a full export take, and what should we test first?

Duration depends on your record counts, attachment volume, MID Server capacity and network path, and no fixed figure applies across instances. Before a full run, test a representative subset: one large table, one table with attachments, and one custom table. Confirm that record counts in the export match the instance, that date and reference fields keep their values, and that the target format handles multi-line text and special characters. Ask your ServiceNow administrator to record timings for each test so the full schedule rests on your own measurements.

What do the export work and its ongoing costs depend on?

The cost has two main parts: people and infrastructure. Labor covers the ServiceNow administrator who configures export sets, the developer who extracts attachments, the analyst who validates records and the security reviewer who approves where files land. Infrastructure covers MID Server capacity, storage for the exported files and any temporary staging space. Most of this is one-time work, but scheduled exports and retained archives recur. When you request a quote, ask for each component to be priced separately, including who holds the data during transfer and how long exported copies are kept.

What do our admins and security team need to provide?

Your administrators need the ServiceNow roles that allow export set creation and access to the tables in scope, plus access to the MID Server host and its file share. Your security team should review where exported files are written, who can read them, how they are encrypted at rest and in transit, and how they are deleted after migration. Compliance owners should confirm whether the data set includes personal information or regulated records, since that determines retention and access rules. Document these approvals before the first export so the evidence trail exists.

Is an export alone enough to move our service desk to another tool?

No, an export is the first step of a migration, not the whole migration. A CSV or XML file contains records but not the workflows, approval rules, service catalog items, notifications or access model that ServiceNow applies to them. Those must be rebuilt in the target tool, and attachments must be moved separately. Before choosing a target such as GLPI, compare its data model with your exported tables, then plan the mapping and rebuild work as separate items with their own owners and tests.

Can we keep an exported copy for audit or fallback without keeping ServiceNow running?

Yes, an exported archive can serve as a read-only reference, but it is not the same as a working instance. Your records remain usable for audit questions, yet they lose live links, workflow history and reports unless you export those too. Confirm with your auditors which evidence they need, such as incident and change history for a defined period, and whether an archive in a flat format meets that need. Set a retention period in writing, since the answer depends on your own regulatory and contractual obligations.

What the export means for the next platform

The files you export from ServiceNow are data, not a working system. A CSV, XML or JSON file holds records and field values, but it carries none of the workflows, business rules, service catalog logic, approval paths or reporting that made the instance useful. Treat the export as raw material for the next platform, and expect the target to need its own design for everything the files do not contain.

Before anything is imported, the target platform needs a written mapping of fields, statuses and relationships. Map each ServiceNow incident, problem, change and configuration item state to a status the new tool actually supports, decide which fields have a home and which are dropped, and define how links between tickets, assets and people are rebuilt. Confirm these choices with the platform owner and your data owner, because a mismatch found after import is far more expensive to correct. The sibling guide on moving ServiceNow ITSM records, assets and CMDB data into GLPI covers the field and status mapping for that target in detail.

Decide the target before you design the export. If you choose GLPI, the export sets, file formats and record selections should be shaped around GLPI's data model rather than what is easiest to pull from the instance. Export only what the mapping needs, confirm which attachments must be extracted separately through REST, and test a sample export against a non-production GLPI instance before committing to a full run. Changing the target after the files are built usually means re-exporting and re-mapping from scratch.

How DeployOpen scopes and delivers an export and exit

DeployOpen approaches an export from ServiceNow as a written scope covering each record type, attachment and format, tested against a copy of the data before any cutover. The work is planned, built, documented and handed over inside your own infrastructure, with ongoing support available as a retainer.

How we scope

Inventory which tables, attachments and audit history you need, and confirm the export limits that apply to your instance.
Agree in writing which formats, MID Server paths and scheduled export sets the extract will use.
Confirm the target platform, data mapping owner and acceptance tests before any work starts, as engagements are fixed-scope.

How we build

Configure export sets on a MID Server and set up the REST extraction job for attachments, which export sets do not cover.
Validate record counts, field mappings and attachment links against the source before loading anything into the target.
Run repeated test extracts so the final cutover uses a tested, repeatable procedure rather than a one-time manual export.

How we hand over

Document each export job, its schedule, its credentials handling and the reconciliation report that proves completeness.
Deliver a record of what was exported, what was excluded and what must be rebuilt by hand, such as workflows and catalog items.
Keep the extracted data and logs in your own storage, with retention and access controls agreed in the written scope.

How we support

Offer ongoing support, upgrades and testing as a retainer after the handover, if your team wants it.
Run follow-up reconciliation checks when the source instance changes during the parallel run period.
Confirm with your own security and records team how exported data must be stored, retained and destroyed once the exit is complete.