XML Export/Import & Data Migration | ServiceNow CSA Part 5

Section 1

XML Export/Import Overview

Every record stored in ServiceNow can be exported as an XML file. This XML is a faithful representation of the record's field values, including its sys_id. Because the sys_id is preserved, the same record can be cleanly reimported into another instance — making XML the most reliable method for migrating individual configuration records.

How to Export a Single Record

Open any record on a form view
Right-click the form header (grey bar) to open the context menu
Select Export → XML
The browser downloads a .xml file for that record

How to Export from a List

Navigate to any list view
Right-click a row (or select rows using checkboxes)
Select Export → XML from the context menu
Exports all selected records into a single XML file
Without selection: exports all records currently visible in the list

How to Import XML

Navigate to: System Definition > XML Import — or use the filter navigator
Alternatively: System Import Sets > Load Data and choose the XML file source
ServiceNow reads the sys_id inside the XML
If a record with that sys_id exists in the target instance: the record is updated
If no record with that sys_id exists: a new record is inserted

Why sys_id Matters: The sys_id is a globally unique identifier that ServiceNow generates for every record. When you export a record as XML, the sys_id travels with it. On import, ServiceNow uses this value to determine whether to update an existing record or create a new one — ensuring configuration records land in exactly the right place on the target instance.

Passport Analogy: Think of a record's sys_id as a passport. When you export XML, the record takes its passport with it. When it arrives at another instance (country), the passport is checked: if someone with that ID already lives there, the record updates them; if not, a new resident is registered. No passport = no guarantee of identity.

Section 2

Export Formats

ServiceNow provides multiple export formats accessible from the right-click context menu on a list row or the form header. Each format has a distinct purpose — the exam tests whether you know which format supports reimport.

Format	Use Case	Reimportable?	Notes
XML	Configuration migration, full-fidelity backup of records	Yes	Preserves `sys_id` and all field values. Gold standard for record migration.
CSV	Flat data analysis, spreadsheet consumption	Not directly	Loses relational context; can be reimported via Import Sets with a Transform Map.
Excel	Formatted spreadsheet reports for stakeholders	No	For sharing/printing. Cannot be used as an import source natively.
PDF	Print-ready or shareable snapshots	No	Read-only output format. No data import capability.
JSON	REST API responses, integration payloads	Via API	Returned by REST API calls; not a native right-click export option in all versions.

Exam Must-Know: Of all the export formats, XML is the only one that can be directly reimported into ServiceNow while preserving sys_id and record relationships. CSV can be imported but requires a Transform Map and does not preserve sys_id automatically. Expect a question contrasting XML with CSV or Excel.

Accessing Export Options

From a List View

Right-click any row in a list to open the context menu. The Export submenu appears with all available format options. If multiple rows are selected via checkboxes, all selected records export together.

From a Form View

Right-click the grey form header bar (the bar showing the table/record name at the top of the form). The context menu includes Export options for the current record.

Section 3

Bulk Export

When you need to export large volumes of records — potentially thousands of rows — ServiceNow provides mechanisms beyond a simple right-click export.

Ad-Hoc Bulk Export

Navigate to a list view and apply filters to scope your records
Select all visible records (or use Select All to include filtered records)
Right-click → Export → XML
For very large datasets, ServiceNow may process the export asynchronously
Large exports are packaged and delivered via email link rather than an immediate download

Scheduled Exports

Navigate to: System Definition > Scheduled Jobs or Reports > Scheduled Reports
Automates regular data extraction on a defined schedule (hourly, daily, weekly)
Useful for keeping external systems in sync with ServiceNow data
Can export to FTP, email, or shared storage depending on configuration

sys_export_log

ServiceNow maintains an audit trail of all export operations in the sys_export_log table. Administrators can review who exported what data and when — important for compliance and data governance.

Navigate via filter navigator: sys_export_log.list

Email Delivery for Large Exports

When an export job is too large to complete synchronously, ServiceNow queues it as a background job. Once complete, the user receives an email containing a download link to retrieve the exported file.

This prevents browser timeouts on large dataset exports.

Best Practice: Before running a bulk export, always apply a meaningful filter to limit the record set. Exporting an entire large table without filters can generate enormous files, trigger email delivery instead of immediate download, and place unnecessary load on the instance.

Section 4

XML Import — Record-Level Migration

XML import is the preferred method for moving individual configuration records between instances. Unlike Import Sets (which are designed for bulk data ingestion), XML import performs a targeted, sys_id-aware upsert directly into the target table.

Import Process Step-by-Step

Step	Action	Location / Detail
1	Export the record from source instance	Right-click form or list row → Export → XML
2	Log in to target instance	Ensure you have `admin` or appropriate import permissions
3	Navigate to XML Import	System Definition > XML Import or type `xml_import.do` in filter navigator URL
4	Upload the XML file	Choose the downloaded XML file from your local machine
5	ServiceNow processes sys_id	Reads `sys_id` from XML; checks target table for existing record
6	Upsert executed	If `sys_id` found: UPDATE existing record. If not found: INSERT new record.

Upsert Defined: An upsert is a database operation that combines update and insert — it updates a record if it exists, or inserts it if it does not. XML import in ServiceNow always performs an upsert keyed on the record's sys_id.

When to Use XML Import

Migrating specific configuration records that are not captured in an Update Set (e.g., custom catalog items, knowledge articles, specific workflow versions)
When you need the record to land with the exact same sys_id on the target instance
Moving a handful of records — not suitable for bulk data migration (use Import Sets for that)
Sharing specific records between developers working on different instances

Reference Fields Warning: If the record being imported contains reference fields (fields that point to other records by sys_id), those referenced records must also exist on the target instance with the same sys_id — otherwise the references will be broken or null after import. Always audit dependencies before migrating configuration records via XML.

Section 5

Data Migration: Import Sets vs. Update Sets vs. XML

One of the most tested areas in Part 5 is understanding which migration tool to use in which scenario. The three mechanisms look superficially similar — all move information between instances — but they serve fundamentally different purposes.

Core Distinction

📦

Update Sets

Move configuration changes — scripts, form layouts, business rules, UI policies, workflows, and other customizations made through the ServiceNow interface.

Think: "What you built or configured."

📊

Import Sets

Move data records in bulk — incidents, users, CIs, assets, and other transactional or reference data. Requires a Transform Map to map source columns to target fields.

Think: "Rows of data from an external source."

📄

XML Export/Import

Move specific records by sys_id — sits between the other two. Best for individual config records not captured in Update Sets, or precise record-level migrations.

Think: "An exact copy of a specific record."

Full Comparison Table

Aspect	Update Sets	Import Sets	XML Export/Import
Primary purpose	Config migration (DEV → TEST → PROD)	Bulk data ingestion from external sources	Record-level migration preserving sys_id
What it moves	Customizations: scripts, forms, rules, workflows	Data rows: users, incidents, CIs, assets	Any individual record type
sys_id preserved?	Yes — captures changes by sys_id	No — Transform Map generates new sys_ids	Yes — explicit sys_id upsert
Transform Map needed?	No	Yes — required for field mapping	No
Staging table used?	No	Yes — `sys_import_set_row`	No
Typical source	ServiceNow DEV instance	External file (CSV, XML, JDBC, LDAP)	ServiceNow instance (any environment)
Volume	Configuration records (usually low volume)	High volume bulk data	Low volume (individual or small sets)
Table stored in	`sys_update_set`	`sys_import_set`	Directly in target table
Best for	Promoting application development changes	Loading data from external systems (HR, CMDB feeds)	Cloning specific records between instances

Exam Scenario — Pick the Right Tool:

"Move a business rule from DEV to PROD" → Update Set
"Load 50,000 employee records from an HR CSV file" → Import Set
"Copy a specific catalog item with its sys_id to a new instance" → XML Export/Import
"Migrate a workflow from TEST to PROD" → Update Set
"Import CI data from a discovery scan file" → Import Set

Import Sets Deep Dive — Key Concepts

Since Import Sets are the tool for bulk data migration, understanding how they work is essential for the exam.

Import Set Table: When you load data, ServiceNow first stages it in a temporary import set table (prefixed with u_)
Transform Map: A configuration record that maps columns in the import set table to fields in the target table
Coalesce: A Transform Map field option that identifies a "match" field — if a record with the same value exists in the target, update it instead of creating a duplicate
Run Transform: After loading data, you run the transform to move records from the staging table to the target table
Import Set Log: Tracks the status of each row (inserted, updated, error, ignored)

Coalesce vs. sys_id: Import Sets use coalescing on a chosen field (like email address or employee number) to match incoming records to existing ones. This is fundamentally different from XML import, which always uses sys_id as the match key. This is why Import Sets do not preserve sys_id by default.

Section 6

MID Server

The MID Server (Management, Instrumentation, and Discovery server) is a Java-based agent application that customers install on a server within their own network. It enables ServiceNow — a cloud-hosted platform — to communicate with systems that are not publicly accessible on the internet.

What MID Server Enables

JDBC Imports

Query databases inside a corporate network using JDBC. Pull data from SQL Server, Oracle, MySQL, etc., directly into Import Sets without exposing the database externally.

LDAP Integration

Connect to on-premise Active Directory or other LDAP servers for user provisioning and authentication — common in enterprise environments with internal identity systems.

Discovery

Probe IP ranges inside the corporate firewall to discover hardware and software assets for the CMDB. MID Server reaches network devices that ServiceNow's cloud cannot directly access.

REST/SOAP to Internal APIs

Call REST or SOAP APIs hosted on internal servers (behind a firewall) on behalf of ServiceNow workflows and integrations.

Orchestration

Run scripts and automation on internal servers as part of ServiceNow workflow orchestration steps.

PowerShell / SSH

Execute commands on Windows (PowerShell) and Linux/Unix (SSH) servers within the customer's network for automation and data collection.

MID Server Architecture

Aspect	Detail
Technology	Java application (JAR-based agent) installed on a customer-managed server
Network direction	Outbound only — MID Server initiates connection TO ServiceNow. ServiceNow never connects inbound to the MID Server.
Firewall requirement	Only outbound port 443 (HTTPS) needs to be open from MID Server to ServiceNow. No inbound firewall rules required.
Location	Customer's own network — behind the corporate firewall, within the same network segment as the target systems
Configuration table	`sys_mid_server` — manage all MID Servers from MID Server > Servers
Status monitoring	MID Server sends heartbeat to ServiceNow; status visible in the `sys_mid_server` record (Up/Down)

The Bridge Analogy: Imagine ServiceNow is a city on one side of a river, and your corporate network is on the other side. Normally they cannot communicate because a firewall separates them. The MID Server is a bridge-keeper who lives on the corporate side — it can reach systems on that side, and it calls across to ServiceNow to report findings. Crucially, ServiceNow never crosses to the corporate side on its own.

Key Exam Fact — Outbound Only: The MID Server connects outbound from the customer network to ServiceNow. This means no inbound firewall ports need to be opened on the customer's firewall. This is a deliberate security design — the corporate network is never exposed. Expect exam questions that test whether you know the direction of communication.

Section 7

Instance Clone

An instance clone copies an entire ServiceNow instance — including all data, configuration, and customizations — from a source instance to a target instance. This is most commonly used to refresh a DEV or TEST environment with real PROD data so that testing is performed against realistic data sets.

Common Clone Scenarios

PROD → DEV

Refresh the development environment with current production data and configuration. Ensures developers are working with a realistic copy of the system.

PROD → TEST

Refresh the test/staging environment before a major release to run acceptance tests against production-equivalent data.

PROD → UAT

Provide business users with a production-like environment for User Acceptance Testing without risk to real data.

Clone Characteristics

Aspect	Detail
What is included	All tables, records, configuration, scripts, customizations, user data — a complete copy
What is excluded	User passwords (reset to default), some external integration credentials, MID Server bindings
Effect on target	Completely destructive — all existing data on the target instance is wiped and replaced. There is no merge; it is a full overwrite.
How to request	Managed via the HI (Hosted Instances) portal — customers submit a clone request through the ServiceNow support portal
Duration	Can take hours depending on instance size; target instance is offline during clone
Passwords after clone	User passwords are excluded — all user accounts will need to reset passwords on the cloned instance

Destructive Operation — Target Data Lost: A clone completely overwrites the target instance. Any development work, test data, or configurations on the target instance that have not been captured in Update Sets or otherwise backed up will be permanently lost. Always communicate with your team before initiating a clone and ensure all in-progress work is saved.

Clone Exclusion Lists: ServiceNow provides a mechanism to exclude specific tables or records from a clone (clone exclusions). This prevents certain data — such as integration tokens, test-specific configurations, or sensitive records — from overwriting the target's own values. Configure exclusions before requesting the clone via the HI portal.

Section 8

Key Exam Facts & Traps

This section consolidates the highest-frequency exam topics for XML migration and data migration within Part 5.

Fact 1 — XML Preserves sys_id: XML export is the safest method for migrating individual configuration records because it preserves the record's sys_id. This ensures referential integrity — other records that reference the exported record by sys_id will still resolve correctly after import.

Fact 2 — Import Sets + Transform Maps: Import Sets use Transform Maps for field mapping. Transform Maps do not preserve sys_id by default — new sys_ids are generated for inserted records unless you explicitly configure coalescing or map the sys_id field in the transform. This is a critical distinction from XML import.

Fact 3 — Right Tool for Config vs. Data:

Update Sets = configuration (scripts, forms, rules) between instances
Import Sets = bulk data (users, incidents, CIs) from external sources
XML Export/Import = specific records with sys_id fidelity

Fact 4 — MID Server Direction: The MID Server always connects outbound from the customer network to ServiceNow. No inbound firewall rules are required on the customer firewall. ServiceNow sends instructions to the MID Server via the outbound connection — it never initiates an inbound connection.

Fact 5 — Clone Destroys Target: An instance clone is completely destructive to the target instance. All existing records and configurations on the target are wiped. Clones are requested via the HI (Hosted Instances) portal, not done directly in the instance UI.

Fact 6 — Large Exports via Email: When an export job is too large to complete synchronously (e.g., exporting tens of thousands of records), ServiceNow queues it as a background job and emails the user a download link when complete. The export is not lost — it is delivered asynchronously.

Fact 7 — sys_export_log: All export operations are tracked in the sys_export_log table. This supports data governance and compliance requirements by providing an audit trail of what was exported, by whom, and when.

Quick Reference — Migration Decision Tree:

Moving a script/form/rule/workflow between instances? → Update Set
Loading bulk external data (CSV, database, LDAP)? → Import Set
Copying a specific record with same sys_id to another instance? → XML Export/Import
Need to communicate with on-premise internal systems? → MID Server
Need a full copy of PROD for testing? → Instance Clone