Freshservice to ServiceNow Migration: The CTO's Technical Guide

Moving from Freshservice to ServiceNow isn't a lift-and-shift. It's a platform-class migration — from a mid-market ITSM tool to an enterprise platform with a fundamentally different data architecture, workflow engine, and CMDB model. The difficulty isn't moving tickets. It's decomposing Freshservice's unified ticket model into ServiceNow's task table hierarchy, rebuilding Workflow Automator logic in Flow Designer, extracting CMDB relationships that Freshservice doesn't natively export, and working within strict API rate limits without dropping records.

This guide covers what actually breaks and how to handle it — with specific table mappings, code examples, and extraction strategies.

For a deeper comparison of both platforms' architectures, see our ServiceNow vs Freshservice: The CTO's 2026 Architecture Guide.

Why Do Companies Outgrow Freshservice for ServiceNow?

Freshservice works well for mid-market IT teams running standard incident and request workflows. It's fast to deploy and easy to maintain. The break point comes when your organization hits one of these walls:

Limited enterprise controls. Freshservice's role-based access is flat compared to ServiceNow's domain separation and granular ACL system. If you need different business units operating in isolated ITSM environments with distinct data visibility rules, Freshservice doesn't have the mechanism. ServiceNow's Access Control Lists allow field-level security based on location, department, or specific data conditions — and domain separation provides full data isolation between business units sharing a single instance.

Shallow ITIL depth. Freshservice supports incidents, service requests, problems, and changes — but the depth of each process is constrained. ServiceNow's Change Management supports standard/normal/emergency change models with CAB workflows, risk assessment scoring, and conflict detection built into the platform. Freshservice's change process is comparatively simplified — no native risk calculation engine, no automated change collision detection.

Cross-department workflow limits. Freshservice has added non-IT workspaces (HR, Facilities), but orchestrating complex, multi-department workflows that span procurement, legal, security, and IT requires the kind of platform-level workflow engine ServiceNow provides through Flow Designer and IntegrationHub. ServiceNow extends beyond IT into HR Service Delivery (HRSD), Security Operations (SecOps), and Customer Service Management (CSM) on a single unified platform.

CMDB scalability. Freshservice's CMDB handles basic asset tracking and CI relationships, but users consistently report limitations when trying to extract asset data via API — particularly around relationship exports and custom field constraints. ServiceNow's CMDB, built on the Common Service Data Model (CSDM), provides a prescriptive framework for modeling services, applications, and infrastructure at enterprise scale. Freshservice has nothing equivalent to CSDM's layered domain structure (Foundation → Design → Build → Manage → Consume).

How to Map Freshservice Data to ServiceNow

This is where most teams underestimate the work. Freshservice and ServiceNow use different data models, different field naming conventions, and different approaches to categorization. A 1:1 mapping is rarely possible.

Ticket Type Mapping

Freshservice uses a unified ticket object with a type differentiator. ServiceNow uses entirely separate tables, all extending the core task table.

Asset Management → ServiceNow ITAM

Freshservice treats assets and CIs as a unified concept within its CMDB. ServiceNow separates IT Asset Management (ITAM) from CMDB — an asset record (alm_hardware, alm_consumable, alm_license) links to a CI record in the CMDB via the ci reference field.

When migrating:

• Hardware assets: Map to the alm_hardware table. ServiceNow automatically creates a corresponding CI in the CMDB when a hardware asset is created, provided model categories are configured correctly. Do not import the same hardware record into both the asset table and the CI table manually — you will create duplicates.
• Software licenses: Map to the alm_license table.
• Lifecycle states: Freshservice lifecycle states (In Use, In Stock, Retired) don't map 1:1 to ServiceNow values. Build an explicit value mapping.
• Financial data: Migrate purchase cost, depreciation, and contract data separately into ServiceNow's asset financial records.

Freshservice CMDB → ServiceNow CMDB (CSDM)

This is the hardest part of the migration. ServiceNow's CMDB follows the Common Service Data Model (CSDM) — a prescriptive framework that organizes CIs into defined classes with standardized relationships. Freshservice's CMDB is flatter: CIs are organized by asset type with custom fields and relationship types defined by the admin.

The critical gap: Freshservice does not natively export CMDB relationships via its standard export or API in bulk. You can export CI records, but the relationship graph — "Uses/Used By," "Depends On," "Connected To" — requires separate API calls per CI (/api/v2/assets/{id}/relationships) or custom scripting to reconstruct. For organizations with hundreds of interconnected CIs, this is a significant extraction challenge that multiplies API call counts dramatically.

You need to:

1. Map each Freshservice CI type to a ServiceNow CMDB class (e.g., cmdb_ci_server, cmdb_ci_win_server, cmdb_ci_app_server, cmdb_ci_database). ServiceNow's CSDM is prescriptive — for example, Business Application data belongs in cmdb_ci_business_app, not cmdb_ci_app. (servicenow.com)
2. Extract and rebuild CI relationships using ServiceNow's cmdb_rel_ci table. Freshservice's relationship model doesn't map 1:1 to ServiceNow's relationship types — you need an explicit relationship type crosswalk.
3. Decide which CSDM maturity phase you're targeting — don't try to migrate into a fully mature CSDM model on day one. Most organizations target CSDM "Crawl" (Foundation data only) during initial migration and mature incrementally.

If you fail to map these relationships, your ServiceNow CMDB will be a flat list of assets, rendering impact analysis, change risk assessment, and service mapping useless.

Knowledge Base → ServiceNow Knowledge

Freshservice Solutions map to the ServiceNow kb_knowledge table within a defined knowledge base and category structure.

Key issues:

• HTML sanitization and inline images: Freshservice stores inline images as hosted CDN URLs. When you decommission your Freshservice instance, those URLs break. You must download each image, upload it to the ServiceNow sys_attachment table, and rewrite the <img> tags in the Knowledge Base HTML body to point to the new ServiceNow attachment sys_id. Skip this step and your KB articles will display broken image icons.
• Category structure: Freshservice uses a Category → Folder → Article hierarchy. ServiceNow uses knowledge bases with category trees and separate manager/reader access controls. Don't assume a 1:1 import shape. (support.freshservice.com)
• Article metadata: Freshservice tracks views and helpfulness ratings — these need explicit mapping to custom fields on ServiceNow's side if you want to preserve them, as kb_knowledge has no standard view count field.

Attachment Migration

Ticket and KB attachments require dedicated handling. ServiceNow stores attachments across two tables: sys_attachment (metadata — file name, content type, table reference) and sys_attachment_doc (actual file content, stored in base64-encoded chunks).

Key constraints:

• ServiceNow attachment size limit: Default maximum is 24 MB per file (configurable via com.glide.attachment.max_size property). Freshservice attachments exceeding this limit will fail on import.
• API upload method: Use the ServiceNow Attachment API (/api/now/attachment/file) with multipart form data. Base64-encoding large files in JSON payloads is slower and doubles memory consumption.
• Batch strategy: For high-volume migrations (100K+ attachments), batch uploads during off-peak hours. Each attachment upload is a separate API call — factor this into your ServiceNow API rate budget.
• Orphan detection: After migration, query sys_attachment for records where the referenced table_sys_id doesn't exist in the target table. Freshservice ticket deletions during migration can create orphaned attachments.

SLA Migration

SLA definitions and breach history are complex to migrate and frequently overlooked:

• SLA definitions: Freshservice SLA policies (response time, resolution time, escalation rules by priority) must be recreated as ServiceNow SLA Definitions in the contract_sla table. These are configuration, not data — rebuild them manually in ServiceNow.
• Elapsed SLA time: Historical SLA elapsed time on open tickets cannot be directly imported. ServiceNow calculates SLA elapsed time dynamically based on task SLA records (task_sla). For open tickets migrated mid-SLA, you need to create task_sla records with backdated start times matching the original Freshservice ticket creation dates.
• Breach history: Freshservice SLA breach records on closed tickets are informational. If you need breach history in ServiceNow for reporting, map them to custom fields or a custom table — ServiceNow's native task_sla records are designed for active SLA tracking, not historical breach archiving.
• Business schedules: Freshservice SLA calculations reference business hours. Ensure your ServiceNow business schedules (cmn_schedule) match your Freshservice business hour definitions before SLA records are created, or elapsed time calculations will diverge.

Agent Groups → Assignment Groups

Freshservice agent groups map to ServiceNow's sys_user_group table. The mapping itself is straightforward, but watch for:

• Migration order: You must migrate users and groups before migrating tickets, as ticket assignment fields reference the sys_id of user and group records.
• Group membership: Freshservice groups reference agents by email/ID; ServiceNow groups reference sys_user records. Build group membership after user records exist.
• Workspace context: In Freshservice, tickets are assigned to workspace, then group, then agent. In ServiceNow, assignment groups are filtered by type on ITSM forms. If you flatten duplicate group names across workspaces without a naming strategy, you create ambiguity on day one. (support.freshservice.com)
• Approval groups: If Freshservice groups were used in approval workflows, those approvals need to be rebuilt in ServiceNow's approval engine — they won't carry over.

Carry Source Identifiers Forward

Import Sets support coalesce logic. Keeping a source-system key on every migrated record makes reruns, rollback, reconciliation, and delta loads much safer. (servicenow.com)

source_system: freshservice
source_table: tickets
source_id: 104233
source_display_id: INC-104233
source_workspace: IT

Add a u_source_system and u_source_id field to every target table. Coalesce on u_source_id so re-running the import updates existing records instead of creating duplicates.

What Breaks During a Freshservice to ServiceNow Migration

Workflows Don't Migrate — They Get Rebuilt

Freshservice Workflow Automator logic cannot be automatically migrated to ServiceNow Flow Designer. There is no vendor-documented conversion path between the two. These are fundamentally different automation engines with different trigger models, action libraries, and execution contexts. (support.freshservice.com)

Freshservice's Workflow Automator uses event-based triggers (ticket created, updated, time-based) with a visual builder that chains conditions, actions, webhook calls, field updates, approvals, and notifications.

ServiceNow's automation framework spans Business Rules (server-side JavaScript), Client Scripts, Scheduled Jobs, and Flow Designer flows. Each Freshservice workflow needs to be manually analyzed, then rebuilt using the appropriate ServiceNow mechanism:

Freshservice API Rate Limits Will Throttle Your Extraction

Freshservice v2 API enforces per-minute rate limits that vary by plan:

These limits are account-wide — shared across all agents, integrations, and API keys hitting the same instance. Freshservice returns HTTP 429 with a Retry-After header when you exceed the limit. Freshservice also states that public APIs are primarily for integration use and are not recommended for large-volume API transactions. (api.freshservice.com)

The numbers add up fast. A mid-sized IT department might have 500,000 tickets, 1.5 million conversations, and 500,000 attachments — 2.5 million individual records. At 200 req/min (Growth plan), that's 12,000 requests per hour. A naive sequential extraction takes over 8 days assuming zero retries or HTTP 429 errors.

Extraction fidelity is its own problem. Standard Freshservice ticket exports top out at 10,000 tickets, omit Service Request item fields, and don't include full conversation history. For complete history you need the Conversations API, and include=conversations on a ticket only returns up to ten conversations while consuming extra API credits. (support.freshservice.com)

The filter/search endpoint (/api/v2/tickets/filter) has an additional hard ceiling: 300 results maximum (30 per page, capped at 10 pages). For filtered ticket extraction of datasets larger than 300 records, you must segment queries by date range or use the list endpoint with updated_since pagination.

Extraction script requirements: Every extraction script needs these capabilities at minimum:

# Pseudocode: Freshservice extraction with rate limit handling
def extract_with_backoff(endpoint, params):
    while True:
        response = requests.get(endpoint, params=params, auth=auth)
        if response.status_code == 200:
            save_checkpoint(endpoint, params)  # checkpoint for restart
            return response.json()
        elif response.status_code == 429:
            retry_after = int(response.headers.get('Retry-After', 60))
            log(f"Rate limited. Retrying after {retry_after}s")
            time.sleep(retry_after)
        else:
            log_error(response.status_code, endpoint)
            raise ExtractionError(response.status_code)

Key requirements: exponential backoff, Retry-After header parsing, checkpoint/restart capability, and per-record error logging. A script that doesn't handle HTTP 429 responses will silently drop records or stall indefinitely.

Freshservice does offer a migration partner program that provides elevated rate limits (700 req/min) via a special token and an X-FW-Partner-Migration header for approved migration partners. This requires submitting a request through Freshservice's internal catalog for a defined migration window.

Sync tools are not migration tools. Exalate and ZigiOps are built for real-time bi-directional synchronization between live systems. That makes them useful for coexistence windows or long-term integration. It does not make them the right tool for a one-time historical move of years of tickets, notes, and CMDB data. Similarly, ServiceNow's IntegrationHub is designed for ongoing integration, not bulk historical data loading.

For teams whose DIY scripts fail mid-migration due to rate limiting, our engineer's rescue guide covers recovery strategies.

Timestamp and Author Preservation

When you create records in ServiceNow via API or Import Sets, the platform automatically sets sys_created_on and sys_created_by to the current timestamp and the API/System user. Every migrated ticket, comment, and work note will appear to have been created by your migration service account at the time of import — unless you explicitly handle it. (servicenow.com)

ServiceNow requires using autoSysFields(false) in GlideRecord scripts or configuring transform map scripts to override system fields. This is not supported through standard REST API inserts. You need either:

• A transform map with an onBefore script that sets autoSysFields(false) and maps the source timestamp/author fields
• A scoped application or background script with appropriate ACL permissions

Here is a working onBefore transform map script:

// onBefore transform map script — timestamp and author preservation
(function runTransformScript(source, map, log, target) {
    // Disable automatic system field population
    target.autoSysFields(false);
 
    // Map original timestamps from import set staging table
    target.sys_created_on = source.u_original_created_on;
    target.sys_created_by = source.u_original_created_by;
    target.sys_updated_on = source.u_original_updated_on;
    target.sys_updated_by = source.u_original_updated_by;
 
})(source, map, log, target);

On the ServiceNow side, the right landing zone is usually Import Sets, not direct table inserts. The Import Set API stages data in an intermediary table and transforms it through transform maps. Key considerations:

• Transformations are asynchronous by default — monitor the transform history (sys_transform_history) for completion and errors
• Import sets run as user system unless explicitly overridden
• ServiceNow warns against importing more than 10,000 records per import set — larger datasets should be chunked into multiple import sets to avoid processing delays or instance health impact
• Import sets cannot write to encrypted fields
• For migration purposes, use a global-scope application or background scripts — scoped applications have restricted access to system tables and fields that migrations frequently need to touch

(servicenow.com)

Migration Approach Decision Tree

Choose your ServiceNow data loading method based on your scenario:

For most Freshservice-to-ServiceNow migrations, Import Sets with scripted transform maps is the recommended approach because it provides staging tables for validation, coalesce logic for idempotent re-runs, transform error logging, and the ability to override system fields via onBefore scripts.

How to Prepare Your Freshservice Instance

The Freshservice-specific prep work is where most timelines are won or lost.

Step 1: Audit Your Freshservice Environment

Before writing a single line of migration code, document:

• Ticket volume by type: Total incidents, SRs, problems, and changes — broken down by status (open vs. closed) and age
• Custom fields per object type: Freshservice allows custom fields on tickets, assets, changes, and problems. Export the field definitions (name, type, dropdown values) for each
• Workflow Automator rules: Count, triggers, and actions for every active workflow
• CMDB CI types and counts: How many asset types exist, how many CIs per type, and how many relationships are defined
• Knowledge base articles: Total count, folder structure, and articles with embedded images or attachments
• Integrations: Any third-party tools connected via API or marketplace apps
• SLA policies: Document every SLA policy, including business hours definitions, priority-based targets, and escalation rules
• Conversation depth: Standard export is ticket-level. Full history requires API or XML, and include=conversations stops at ten results per ticket unless you paginate via /api/v2/tickets/{id}/conversations

Step 2: Clean Before You Move

Migrating junk data into ServiceNow is expensive. ServiceNow licensing costs can scale with data volume (particularly for ITOM and ITAM modules where CI and asset counts affect subscription tiers), and a bloated CMDB will undermine every downstream process.

• Archive or delete resolved tickets older than your retention policy requires. Ask whether you actually need 7 years of closed tickets in ServiceNow — migrating 12–24 months of active and recent data and archiving the rest is often the pragmatic choice. It reduces migration risk and keeps ServiceNow performance clean.
• Merge duplicate CIs and contacts.
• Standardize category and subcategory values — ServiceNow's structured data model has less tolerance for inconsistency.
• Remove orphaned attachments and test data.
• Normalize custom CI types and relationship types before mapping into ServiceNow classes. Freshservice's own asset import guidance calls out duplicate serial numbers and asset-type mismatches as common errors. Those same inconsistencies will surface when you map into ServiceNow. (support.freshservice.com)

Step 3: Build Your Field Mapping Document

Create a spreadsheet mapping every Freshservice field to its ServiceNow target. Pay special attention to:

• Priority values: Freshservice uses 1 (Low) through 4 (Urgent). ServiceNow uses 1 (Critical) through 5 (Planning). The scales are inverted and different in range. A Freshservice priority 4 (Urgent) should map to ServiceNow priority 1 (Critical), and Freshservice priority 1 (Low) should map to ServiceNow priority 4 (Low) or 5 (Planning).

• Status values: Freshservice ticket statuses (Open = 2, Pending = 3, Resolved = 4, Closed = 5) don't map directly to ServiceNow's incident states (New = 1, In Progress = 2, On Hold = 3, Resolved = 6, Closed = 7). Custom statuses in Freshservice require explicit mapping.
• Impact and Urgency: Freshservice has separate Impact (1–3) and Urgency fields. ServiceNow uses Impact and Urgency to calculate Priority via a priority lookup matrix. Decide whether to map Freshservice's priority directly or decompose it into ServiceNow's Impact × Urgency calculation.
• Custom field types: Freshservice dropdown fields need their values mapped to ServiceNow choice list values. Multi-select fields in Freshservice may not have direct equivalents — ServiceNow uses glide_list fields or related list patterns instead.

Step 4: Disable ServiceNow Notifications During Import

This is a critical, often-missed step. ServiceNow sends email notifications when tickets are created, updated, or assigned.

If you import 500,000 historical tickets without disabling outbound email, ServiceNow will email your entire company, notifying them that tickets from three years ago have been "updated." Set glide.email.read.active = false and glide.email.outbound.active = false in System Properties during the import window. Also disable any Event-driven notifications by deactivating relevant Business Rules that generate events. Re-enable after validation.

Step 5: Prepare the ServiceNow Landing Zone

Before importing any data:

• Create custom fields (u_source_system, u_source_id, u_source_display_id) on all target tables for source record tracking
• Create Import Set staging tables for each source entity (tickets, assets, CIs, KB articles, users)
• Configure transform maps with field mappings, coalesce rules, and onBefore scripts for timestamp preservation
• Create a dedicated migration user with the admin role and the import_set_loader role
• Set up Update Sets to package all migration-related configuration (custom fields, transform maps, staging tables) for promotion from dev → test → prod
• Tune instance performance: Increase the glide.db.max_transactions property if needed, and schedule imports during off-peak hours

For a complete list of pre- and post-migration checks, review our Post-Migration QA Checklist.

Post-Migration Validation

Validation is where migrations succeed or fail. Run these reconciliation checks before declaring the migration complete:

Record Count Reconciliation

// GlideRecord: Count migrated incidents by source system
var ga = new GlideAggregate('incident');
ga.addQuery('u_source_system', 'freshservice');
ga.addAggregate('COUNT');
ga.query();
if (ga.next()) {
    gs.info('Migrated incidents: ' + ga.getAggregate('COUNT'));
}

Compare counts against Freshservice source queries for every migrated entity: incidents, service requests, problems, changes, CIs, assets, KB articles, users, and groups.

Field Value Spot-Checks

Sample 1–2% of migrated records and verify:

• Priority values mapped correctly (inverted scale)
• Status values mapped correctly
• Assignment groups resolve to the correct sys_user_group
• Custom field values transferred without truncation or encoding issues
• Timestamps match source records (not the migration date)
• sys_created_by reflects the original requester/agent, not the migration user

Relationship Integrity

// Verify CMDB relationships migrated correctly
var rel = new GlideRecord('cmdb_rel_ci');
rel.addQuery('parent.u_source_system', 'freshservice');
rel.query();
gs.info('Migrated CMDB relationships: ' + rel.getRowCount());

Go/No-Go Decision Criteria

If any check fails, use the coalesce key (u_source_id) to identify and re-run affected records without duplicating successfully migrated data.

Common Pitfalls and How to Avoid Them

1. Mapping every ticket to Incident. Freshservice distinguishes incidents from service requests, and ServiceNow distinguishes them even more strongly. Service Request data belongs on Requested Items with request variables, not on the incident table. If you force it into generic incident fields, reports and fulfillment logic break immediately. (support.freshservice.com)

2. Ignoring the ServiceNow service catalog structure. Teams try to migrate Freshservice service items as flat records. ServiceNow's catalog model uses catalog items → variable sets → variables → order guides. Plan the catalog architecture before migrating request data.

3. Running API extraction without rate limit handling. Every DIY migration script needs exponential backoff, Retry-After header parsing, and checkpoint/restart capability. A script that doesn't handle HTTP 429 responses will silently drop records or stall indefinitely.

4. Flattening assignment groups without workspace context. Freshservice groups are workspace-scoped; ServiceNow assignment groups are type-filtered on ITSM forms. Flatten without a naming strategy (e.g., prefixing with workspace name: IT - Desktop Support, HR - Desktop Support) and you get ambiguity on day one.

5. Treating a Freshservice CI type as a ServiceNow class. ServiceNow's CSDM is prescriptive — cmdb_ci_business_app is not the same as cmdb_ci_app. Map deliberately using ServiceNow's CSDM documentation as the reference.

6. Copying the knowledge hierarchy verbatim. Freshservice is Category → Folder → Article. ServiceNow uses knowledge bases plus category trees with separate manager/reader controls. The structures are not equivalent — plan a new KB taxonomy.

7. Skipping parallel-run testing. Run both systems in parallel for at least one sprint cycle (2 weeks). Create test tickets in both environments, validate routing, SLA calculation, and notification behavior before cutting over.

8. Importing into a ServiceNow instance with existing data without a merge strategy. If your target ServiceNow instance already has production records, you need conflict resolution rules — what happens when a migrated user already exists? When a CI with the same serial number is already in the CMDB? Define coalesce fields and update-vs-skip logic for every entity before importing.

9. Forgetting to package migration configuration in Update Sets. Custom fields, transform maps, and staging tables created in dev must be promoted to test and prod via Update Sets. If you configure everything directly in production, you skip the testing phase entirely.

10. Not accounting for ServiceNow's character limits. ServiceNow string fields default to 40–255 characters. Freshservice custom fields may contain longer text. Check field lengths during mapping and extend ServiceNow field sizes or use journal fields for long text.

What's the Typical Migration Timeline?

A Freshservice-to-ServiceNow migration timeline depends on several variables:

Realistic timeline for a mid-market company (50K tickets, 20 custom fields, 10 workflows, basic CMDB): 3–6 weeks end-to-end, including environment prep, data migration, workflow rebuild, UAT, and cutover.

Enterprise environments (500K+ tickets, complex CMDB, 50+ workflows, multiple integrations): 8–16 weeks, with the bulk of time spent on CMDB restructuring and workflow reimplementation — not the data transfer itself.

The actual data transfer — extracting from Freshservice and loading into ServiceNow — can often be completed in 3–7 days. It's the preparation, field mapping, workflow rebuild, and validation that consume the timeline. The final cutover should happen over a single weekend with a documented rollback plan.

Rollback plan: Before cutover, snapshot your ServiceNow instance. If post-cutover validation fails, you can revert the instance and extend the parallel-run period. The coalesce keys on migrated records allow selective re-migration of failed entities without a full rollback.

How ClonePartner Handles Freshservice to ServiceNow Migrations

We've completed 1,500+ data migrations across ITSM, CRM, and ERP platforms. Freshservice-to-ServiceNow is a path we've engineered specific tooling for.

Here's what that looks like in practice:

• Automated rate limit handling: Our extraction engine respects Freshservice's per-minute limits with intelligent throttling, Retry-After header parsing, and checkpoint recovery — no records dropped, no manual restarts. We work within Freshservice's migration partner program for elevated API limits (700 req/min) when available.
• Timestamp and author preservation: We map original created_at, updated_at, and agent/requester identifiers to ServiceNow's sys_created_on, sys_created_by, and sys_updated_on fields using scripted transform maps with autoSysFields(false) — so your ticket history looks exactly as it did in Freshservice.
• CMDB relationship reconstruction: We extract CI relationships programmatically from Freshservice and rebuild them in ServiceNow's cmdb_rel_ci table, mapped to CSDM-aligned classes.
• Inline image preservation: We download every inline image from Freshservice KB articles, re-host them in ServiceNow's sys_attachment table, and rewrite the HTML — so nothing breaks when Freshservice is decommissioned.
• SLA continuity: We backdate task_sla records for open tickets so SLA elapsed time calculations continue accurately in ServiceNow.
• Zero-downtime cutover: Your support team keeps working in Freshservice during migration. We sync delta changes right up to the cutover moment. Learn more in our zero-downtime migration guide.

We're SOC 2 Type II certified, ISO 27001, HIPAA, and GDPR compliant. Data is encrypted in transit (TLS 1.2+) and at rest (AES-256), and we can route data within specific geographic regions to meet data sovereignty requirements.