--- title: "SolarWinds Service Desk to Ada Migration: Technical Guide" slug: solarwinds-service-desk-to-ada-migration-technical-guide date: 2026-08-10 author: Abdul categories: [SolarWinds Service Desk, Migration Guide, Help Desk] excerpt: "Technical guide to migrating SolarWinds Service Desk to Ada. Covers API extraction, data model mapping, knowledge import, rate limits, and common failure modes." tldr: "Only SWSD knowledge articles, users, and select incidents have an Ada equivalent. Prioritize knowledge transfer — it directly powers Ada's AI agent. Archive everything else." canonical: https://clonepartner.com/blog/solarwinds-service-desk-to-ada-migration-technical-guide/ --- # SolarWinds Service Desk to Ada Migration: Technical Guide # SolarWinds Service Desk to Ada Migration: Technical Guide Migrating from SolarWinds Service Desk (SWSD) to Ada is not a standard help desk migration. You are not moving tickets from one service desk to another. SWSD is an [ITIL-centric service management platform](https://clonepartner.com/blog/blog/solarwinds-service-desk-to-salesforce-service-cloud-migration-guide/) built on incidents, problems, changes, releases, assets, CMDB records, and service catalog workflows. Ada is an agentic customer experience (ACX) platform where AI agents resolve customer inquiries autonomously across chat, voice, and email. These are architecturally incompatible systems, and only a fraction of your SWSD data has a meaningful destination in Ada. The practical pattern that works: extract knowledge from SWSD, transform it for Ada's AI agent, map live customer context into Ada's end-user model, archive everything else in a data warehouse, and connect Ada to a human escalation path for unresolved issues. If you attempt a raw API dump of SWSD incidents into Ada, the migration will fail. This guide covers the extraction mechanics from SWSD's API, the transformation pipeline, Ada's import paths and constraints, data model gaps, and the edge cases you will hit during the move. > [!NOTE] > **Quick Answer:** This migration is a [structural transformation](https://clonepartner.com/blog/blog/solarwinds-service-desk-to-dixa-migration-technical-guide/), not a like-for-like swap. SWSD incidents (with comments) can be archived, curated into knowledge, or partially replayed as Ada conversations. Problems, changes, releases, assets, and CMDB records have **no Ada equivalent** and must be archived separately. SWSD's REST API (`api.samanage.com`) uses offset pagination. Ada's Platform API defaults to 10,000 requests/day, 100/minute, and 10/second, with the End Users and Conversations APIs allowing up to 60,000 requests/day (300/minute, 30/second). Ada's Knowledge API supports up to 50,000 articles per AI Agent with a 100KB max per article and a 10MB max request payload. A typical migration for 30,000–100,000 incidents takes 3–5 weeks including mapping, test runs, knowledge import, and cutover. > > *Written 2025–2026. Targets SWSD API v2.1 and Ada Platform API v2.* --- ## Migration at a Glance The following table is the authoritative reference for every SWSD object, its migration path, the Ada API endpoint used, and the binding constraint. | SWSD Object | Migration Path | Ada API Endpoint | Key Constraint | |---|---|---|---| | Solutions (KB articles) | → Ada Knowledge Articles | `POST /api/v2/knowledge/articles/` | 100KB/article, 50,000/agent | | Incidents (resolved) | Archive + curate into knowledge | `POST /api/v2/knowledge/articles/` | Editorial review required; not a raw copy | | Incidents (open at cutover) | Keep in SWSD until resolved; then archive | N/A | See cutover section below | | Incident comments | → Conversation messages (if replaying) | `POST /v2/conversations/messages/` | Text-only; no images; no original timestamps | | Users (requesters) | → End Users | `POST /v2/end-users/` | 24-hour auto-deletion if no conversation linked | | Users (agents/technicians) | Do not migrate | N/A | Ada uses AI agents, not human agent rosters | | Problems | Archive to cold storage | N/A | No Ada equivalent | | Changes | Archive to cold storage | N/A | No Ada equivalent | | Releases | Archive to cold storage | N/A | No Ada equivalent | | Assets / CMDB | Archive to cold storage | N/A | No Ada equivalent | | Service Catalog items | Archive; rebuild as Ada Processes | N/A | No direct equivalent | | SLA policies | Archive; rebuild as Ada Coaching rules | N/A | No SLA concept in Ada | | Automations / Workflows | Archive; rebuild as Ada Actions + Processes | N/A | Must be rebuilt manually | | Custom fields | → End User `profile.metadata` | `POST /v2/end-users/` | String/integer/boolean only | | Attachments | Re-host to CDN; link in articles | External CDN + Knowledge API | Ada is not a permanent attachment store | --- ## Why Teams Migrate from SolarWinds Service Desk to Ada SWSD is designed for internal IT operations — incident escalation, change management, asset tracking, and SLA enforcement. Its core objects are incidents linked to a relational database of assets, problems, changes, and approval workflows. Ada is an AI-first resolution engine. Its core object is the **Conversation** — a chronological thread between an end user and an AI agent or human agent. Ada empowers enterprises to manage AI agents that resolve customer inquiries autonomously across voice, messaging, and email channels. **Ada-specific terms used throughout this guide:** - **Process** — A multi-step automated workflow in Ada that handles structured tasks (e.g., password reset, order lookup). The equivalent of SWSD automation rules, rebuilt from scratch. - **Coaching** — Ada's instruction layer that shapes how the AI agent responds, enforces policies, and avoids certain topics. SLA escalation logic is often rebuilt here. - **Action** — An integration call or system operation triggered within an Ada conversation (e.g., API lookup, ticket creation). - **Knowledge Source** — A logical container grouping Ada knowledge articles; the top-level object before articles can be created. Common drivers for this migration: - **AI-first customer support.** Teams [replacing a traditional ITSM ticketing workflow](https://clonepartner.com/blog/blog/solarwinds-service-desk-to-livechat-migration-technical-guide/) with Ada's AI agents that can autonomously resolve inquiries without human intervention. - **Knowledge base transfer.** SWSD's solutions (knowledge articles) need to feed Ada's AI agent so it can generate accurate, context-aware responses from day one. - **Conversation history preservation.** Teams want historical incident data available in Ada so human agents have context on prior interactions during handoffs. - **Platform consolidation.** Replacing SWSD plus a separate chatbot with Ada's unified platform that handles both automated resolution and human handoff. --- ## What Data Can You Migrate from SWSD to Ada? Only a subset of your SWSD data has a home in Ada. This is the most important thing to understand before you start. | SWSD Object | Ada Equivalent | Migrates? | Notes | |---|---|---|---| | Solutions (KB articles) | Knowledge Articles | ✅ Yes | Highest-ROI path. Via Knowledge API — Sources, Articles, Tags. | | Incidents | Conversations or Knowledge | ⚠️ Partial | Archive, curate into knowledge, or replay as historical conversations | | Incident comments | Messages | ⚠️ Partial | Text-only; attachments require separate handling. Private notes need redaction. | | Users (requesters) | End Users | ✅ Yes | Map email, name, metadata | | Users (agents/technicians) | N/A | ❌ No | Ada uses AI agents, not human agent roster records | | Problems | N/A | ❌ No | No Ada equivalent; archive to cold storage | | Changes | N/A | ❌ No | No Ada equivalent | | Releases | N/A | ❌ No | No Ada equivalent | | Assets / CMDB | N/A | ❌ No | No Ada equivalent | | Service Catalog items | N/A | ❌ No | No Ada equivalent | | SLA policies | N/A | ❌ No | Must be rebuilt as Ada Coaching rules | | Automations / Workflows | N/A | ❌ No | Must be rebuilt as Ada Actions and Processes | | Custom fields | End User metadata | ⚠️ Partial | String/integer/boolean only in `profile.metadata` | | Attachments | Limited | ⚠️ Partial | Ada attachment upload is limited to handoff state; returns presigned URLs valid up to 7 days. Not a permanent repository. | > [!WARNING] > **Data you will lose:** Problems, changes, releases, assets, CMDB relationships, approval workflows, SLA configurations, and automation rules have no target in Ada. Export these to CSV/JSON and archive them in a data warehouse before decommissioning SWSD. This is not optional — it is a compliance and audit requirement for most organizations. If legal, compliance, or audit teams need exact ticket chronology, original timestamps, or full attachment fidelity, keep SWSD data in a warehouse or read-only archive and expose it separately. --- ## SWSD API: Extraction Mechanics All extraction runs against the SWSD REST API at `api.samanage.com` using API version 2.1. SolarWinds uses token-based API auth. Only Service Desk administrators can generate tokens, and regenerating a token invalidates previously generated tokens. Build exports so token rotation is planned, not accidental. ### Key endpoints for extraction ``` GET /incidents.json?per_page=200&page={n}&layout=long GET /incidents/{id}/comments.json GET /users.json?per_page=200&page={n} GET /solutions.json?per_page=200&page={n} GET /categories.json GET /groups.json ``` The `layout=long` parameter is critical for incidents. Without it, you get a short-form response that omits custom fields, audit history, and nested relationships. ### Pagination and rate limits SWSD uses offset pagination. There is no cursor-based option. You must loop through pages until the response is empty. ```bash curl -H "X-Samanage-Authorization: Bearer YOUR_TOKEN" \ -H "Accept: application/vnd.samanage.v2.1+json" \ -X GET "https://api.samanage.com/solutions.json?page=1&per_page=200" ``` > [!WARNING] > **Rate limits vary by plan tier.** SolarWinds' April 2024 release notes state the Essentials plan allows 100 API calls per minute (except user provisioning actions at 1,500/minute). Advanced allows up to 1,000 calls/minute; Premier up to 1,500/minute per the April 2023 enforcement announcement. There are no rate-limit response headers in SWSD — the API does not return `X-RateLimit-*` headers. Build conservative backoff logic (start at 60–80 requests/minute) and confirm the live limit in your tenant before a bulk export. ### Extraction gotchas - **Attachment download gaps.** SWSD's API lets you attach files to incidents but does not provide a consistent programmatic download endpoint across all plan tiers. Verify your plan's API surface and test attachment retrieval before committing to a timeline. - **CSV export cell limits.** If you use CSV as a fallback extraction method, any cell containing over 32,767 characters causes misaligned rows when opened in Excel. Preprocess long-text fields. - **Source platform drift.** In SolarWinds' June 2026 release notes, Task Management v2 requires migration of existing tasks and explicitly states that Task Management v2 has no API support. If your source tenant is moving to Task Management v2 during the migration, freeze task scope early. - **Scheduled backups.** Customers can request a weekly scheduled backup in CSV format, and manual CSV exports are available at any time. Use this as a safety net alongside API extraction. - **`description_no_html` shortcut.** SWSD exposes a `description_no_html` field on incidents that strips tags but discards formatting. Useful for quick extraction of incident descriptions, but insufficient for solution articles where heading structure carries semantic meaning. - **SAML/SSO user records.** If your SWSD tenant uses SAML-based SSO, user records in SWSD may not carry email addresses in the standard `email` field — identity is often asserted by the IdP at login. Audit your user export for null or placeholder email values before mapping to Ada's End Users API, which requires a valid email for deduplication. - **Sub-category hierarchy.** SWSD supports nested categories and sub-categories. Ada's Knowledge API uses a flat tag model — there is no parent-child tag relationship. Map SWSD category + sub-category combinations to compound tags (e.g., `network-vpn`, `hardware-laptop`) rather than trying to preserve hierarchy. Document the flattening rules before transformation begins. --- ## Transforming SWSD Data for Ada SWSD data is not Ada-ready. Every record needs transformation before it can be ingested by Ada's AI reasoning engine. ### Cleaning HTML for Ada's LLM SWSD solution bodies and incident descriptions are stored as raw HTML with nested tables, inline styles, and `
` wrappers. Ada's generative AI models perform best with clean, structured text. **Why this matters quantifiably:** A typical SWSD knowledge article body averages 8,000–15,000 characters of raw HTML. After stripping tags and converting to Markdown, the same content compresses to 2,000–5,000 characters — a 60–75% token reduction. At Ada's 100KB article limit, raw HTML will push articles over the threshold that clean Markdown would not. HTML artifacts like `
` carry zero semantic value for the LLM but consume context window space identically to content-bearing tokens. Convert HTML to clean Markdown before loading: ```python import requests from bs4 import BeautifulSoup import markdownify def clean_swsd_html(html_content): soup = BeautifulSoup(html_content, 'html.parser') # Remove styling, scripts, and empty tags for tag in soup(['style', 'script', 'meta']): tag.decompose() # Convert cleaned HTML to Markdown clean_text = markdownify.markdownify(str(soup), heading_style="ATX") return clean_text.strip() ``` SWSD also exposes a `description_no_html` field on incidents, which strips tags but loses heading structure. Use full HTML parsing for solution articles. ### Re-hosting inline images SWSD hosts inline images and attachments on AWS S3. The URLs provided in the API response are authenticated and rely on expiring signatures. If you migrate an article to Ada and leave the SWSD image URLs intact, images will break as soon as the signature expires or the SWSD instance is deprecated. To handle this: 1. Parse the SWSD `description` HTML for `` tags. 2. Download the image file locally using your SWSD API token. 3. Upload the image to a public CDN or your own S3 bucket. 4. Replace the old SWSD URL with the new public URL in the text before pushing to Ada. If an image contains critical instructional data (e.g., a screenshot of a software interface), run it through an OCR pipeline to extract the text. Append this text to the article so Ada's LLM can read the image content. ### Scrubbing PII SWSD incidents and comments routinely contain phone numbers, email addresses, IP addresses, employee IDs, and physical locations. Before feeding any data into Ada — whether as knowledge articles or conversation history — strip PII using regex patterns, a data-loss prevention (DLP) tool, or both. **GDPR and CCPA implications:** Replicating personal data from SWSD into Ada constitutes a new processing activity under GDPR Article 5 and may trigger data subject rights obligations under CCPA Section 1798.100. Specifically: - If the Ada environment is hosted in a different region than your SWSD tenant, cross-border transfer rules (GDPR Chapter V) apply. - Incident data containing EU data subject PII must be assessed under a Transfer Impact Assessment if moving to a non-adequate country. - CCPA requires that personal information collected for internal IT operations not be used for a materially different purpose (customer-facing AI support) without updated privacy notices. - The safest approach: anonymize or pseudonymize all incident-derived content before loading into Ada. Treat Ada knowledge articles as public-facing by default unless you have explicit access controls. > [!CAUTION] > **Internal vs. external knowledge:** SWSD Solutions have a `state` field (Draft, Published, Internal). SWSD comments can be public or private, and the platform allows converting private to public but not the reverse. You must filter out internal articles and private notes before pushing data to Ada, or explicitly tag them if using Ada for internal employee support. Feeding internal credentials or private IT procedures to a public-facing Ada bot is a severe security risk. ### Handling multilingual SWSD content Enterprise SWSD tenants often contain knowledge articles in multiple languages. Ada's End Users API includes a `language` field (BCP 47 language tags, e.g., `en`, `fr`, `de`) that controls which language the AI agent responds in for a given user. However, Ada's knowledge retrieval does not automatically filter articles by language — it relies on the article content itself being in the correct language for the user's session. For multilingual migrations: - Tag articles with their source language (e.g., `lang-fr`, `lang-de`) during import. - Store each language version of an article as a separate Ada knowledge article, not concatenated into one. - Set the `language` field on End User records to match the primary language of that user's SWSD incidents. - Validate that generative answers are drawn from language-matched articles using Ada's Interactive Testing before go-live. --- ## Ada API: Import Paths Ada exposes several API families relevant to migration. All are REST, JSON-formatted, and authenticated via rotatable API keys passed in the `Authorization` header. Verify each endpoint path against Ada's current API reference documentation before implementation — Ada's base URL for API calls is `https://api.ada.support` and the documentation reference base is `https://docs.ada.cx`. ### Knowledge API (Highest ROI) This is the most valuable import path. Transferring your SWSD knowledge base directly improves the AI agent's ability to answer customer questions accurately from day one. The Knowledge API exposes three resources: **Sources**, **Articles**, and **Tags**. ``` POST /api/v2/knowledge/sources/ # Create a knowledge source POST /api/v2/knowledge/articles/ # Create articles within a source POST /api/v2/knowledge/tags/ # Create tags for organization ``` Every article must be associated with a source. Create a source named something like "SWSD Knowledge Base" first, then load articles under it. **Key constraints:** - Up to 50,000 articles per AI Agent by default - 100KB max per article - 10MB max per request payload - Rate limited at 10,000 requests/day, 100/minute, 10/second (Platform API defaults) - Newly created or updated content typically begins indexing within ~30 seconds but may take up to several minutes to become consistently available to generative answers - Import knowledge articles at least 24 hours before go-live to ensure full indexing **If your SWSD knowledge is already publicly accessible,** Ada's Web Import can be faster than building a custom extractor. The trade-offs: only public pages, 100KB per article, up to five link levels deep. For anything private, structured, or requiring transformation, use the Knowledge API. Ensure your load script handles HTTP 429 errors with exponential backoff: ```python import time import requests def push_to_ada(payload, headers, max_retries=5): url = "https://api.ada.support/api/v2/knowledge/articles/" for attempt in range(max_retries): response = requests.post(url, json=payload, headers=headers) if response.status_code == 201: return response.json() elif response.status_code == 429: sleep_time = (2 ** attempt) time.sleep(sleep_time) else: raise Exception(f"Ada API Error: {response.status_code} - {response.text}") ``` ### End Users API Use `POST /v2/end-users/` to create end user records from SWSD requester data. ```json POST /v2/end-users/ { "external_id": "swsd_user_12345", "profile": { "name": "Jane Doe", "email": "jane@example.com", "language": "en", "metadata": { "swsd_user_id": "12345", "department": "Engineering" } } } ``` > [!CAUTION] > **24-hour auto-deletion rule.** End users created via `POST /v2/end-users/` that are not associated with a conversation within 24 hours are automatically deleted. You must create the end user and start a conversation for them within that window. Batch your user creation and conversation creation together — do not create all users first and then circle back to create conversations days later. With 60,000 requests/day and 300/minute limits on this API, you can process roughly 20,000 user+conversation pairs per day (each pair requires at minimum 3 API calls: create user, create conversation, add first message). The End Users and Conversations APIs support up to 60,000 requests per day, 300 per minute, and 30 per second. ### Conversations API The Conversations API lets you create and manage conversations programmatically. You can use it to replay SWSD incident history as Ada conversations, though this approach has significant limitations. ```json POST /v2/conversations/ { "end_user_id": "ada_end_user_id", "channel": { "type": "custom", "id": "swsd-migration" } } ``` **Key limitations:** - **Text-only.** Only text messages are supported. Images and structured messages are not available. Inline images, embedded screenshots, and file attachments from SWSD incident comments must be converted to text descriptions, stored externally with links, or dropped. - **Read-only timestamps.** Ada generates its own `created_at` and `updated_at` values. You cannot import original SWSD timestamps. If chronological order matters for audit or compliance, preserve original timestamps in `profile.metadata` on the conversation or end user record. - **No idempotency.** If your migration script retries a failed request and the original succeeded, you get duplicate conversations. Track created conversation IDs in a local state table keyed on `swsd_incident_id`. - **No native channel creation.** You cannot create conversations on native Chat or Voice channels. Use a custom channel type for migration imports. - **Email conversation constraints.** The native email endpoint caps incoming inquiry text at 10KB with 4KB of metadata. - **Conversation metadata is storage-only.** Metadata set on a conversation does not create metavariables and does not drive routing or answer selection. If a field must influence the bot's behavior from the first turn, set it through the End Users API or another supported variable path. ### Handoffs API Ada documents native handoff paths for Zendesk, Salesforce, ServiceNow, Genesys, and Amazon Connect. As of early 2026, the Handoffs API is generally available for custom integrations to any live agent platform. If you need a human escalation path that doesn't match a native integration, this is the entry point. --- ## SWSD Solutions → Ada Knowledge Articles This is the migration path with the highest ROI. SWSD Solutions already behave like a knowledge base and can be surfaced to end users through the portal. ### Extraction ``` GET /solutions.json?per_page=200&page={n} ``` Each solution has a `title`, `description` (HTML body), `category`, `state`, and optionally nested attachments. ### Transformation 1. **Filter by state.** Only pull Published articles for public-facing bots. For internal employee support bots, Internal articles may be included — tag them explicitly and verify Ada access controls are in place. 2. **Strip HTML.** Convert `description` to clean Markdown (see transformation section above). 3. **Map categories to tags.** SWSD solution categories become Ada tags. SWSD sub-categories become compound tags (e.g., `network-vpn`). Create tags first via the Knowledge API, then reference them when creating articles. 4. **Re-host embedded images.** Download from SWSD's authenticated S3 URLs, upload to your CDN, and update links. 5. **Check character limits.** Validate against Ada's 100KB article limit. Split oversized articles at logical section boundaries — do not truncate mid-sentence. 6. **Handle multilingual articles.** Store each language version as a separate article; tag with `lang-{code}`. ### Load ```json POST /api/v2/knowledge/sources/ { "name": "SWSD Knowledge Base", "description": "Migrated from SolarWinds Service Desk" } POST /api/v2/knowledge/articles/ { "source_id": "", "title": "How to Reset Your VPN Password", "content": "Step 1: Navigate to...", "tags": ["vpn", "password-reset", "network"] } ``` --- ## SWSD Incidents: Archive, Curate, or Replay How you handle SWSD incidents depends on your goals. There are three valid approaches, and you may combine them. ### Decision framework | Goal | Recommended approach | |---|---| | Power Ada's AI agent with knowledge | Curate into knowledge articles (Option 2) | | Preserve compliance/audit record | Archive to data warehouse (Option 1) | | Give human agents prior-interaction context | Replay as conversations (Option 3) | | Minimize migration complexity | Archive only (Option 1) | ### Option 1: Archive (default for most teams) Export incidents, comments, and attachments to a data warehouse or object store. Keep them accessible for compliance, audit, and edge-case debugging. Do not push them into Ada. This is the safest path and the right choice if your primary goal is powering Ada's AI agent with knowledge, not preserving ticket history. ### Option 2: Curate into knowledge Mine recurring resolved incidents for repeatable resolutions and promote them into Ada as knowledge articles. High-effort but high-value for teams with strong data maturity. The synthesis pipeline: 1. Query SWSD incidents: `GET /incidents.json?layout=long` 2. Filter for `state` of "Resolved" or "Closed." 3. Extract the initial user `description` (the question) and the final agent comment or solution comment (the answer). 4. Deduplicate — group by category and subcategory to find recurring patterns. Incidents appearing 5+ times with similar descriptions are strong candidates. 5. Sanitize — strip greetings, signatures, PII, and internal-only language. 6. Normalize — rewrite one-off case details into general guidance. 7. Load the curated Q&A pairs as Ada knowledge articles. This is not a copy-paste operation. Each synthesized article needs editorial review to ensure it is customer-safe and factually accurate. ### Option 3: Replay as conversations Use Ada's Conversations API to replay SWSD incidents as historical conversation threads. This gives human agents context on prior interactions during handoffs. **Trade-offs:** - Ada-generated timestamps replace original dates — you lose chronological fidelity in the Ada interface. Store original `created_at` in `profile.metadata` if needed. - Text-only: all attachments, images, and rich formatting are stripped. - No idempotency: maintain a state table to prevent duplicates. - The 24-hour auto-deletion rule means you must batch user creation with conversation creation. - This does **not** influence Ada's AI agent behavior. Only knowledge articles drive generative answers. For most teams, Option 1 + Option 2 delivers the best results. Option 3 adds value only if human agents actively need historical conversation context in Ada's interface during the transition period. ### Handling open incidents at cutover The guide above covers historical (resolved/closed) incidents, but every live migration has open tickets at the moment of switching. Three patterns: 1. **Hard cutover with SWSD freeze.** Set a cutover date, stop accepting new SWSD tickets 24–48 hours before, work down the open queue, then switch. This minimizes data split but requires a service pause. 2. **Parallel operation.** Run SWSD for in-flight incidents and Ada for new inquiries simultaneously. Maintain SWSD in read-only mode for historical reference. Disadvantage: agents work two systems during the overlap period. 3. **Incident-by-incident migration.** As each open SWSD incident is resolved, archive it and create the corresponding Ada record. This is operationally clean but extends the migration window. Most teams choose Option 2 (parallel operation) with a defined end date — typically 30 days — after which all in-flight incidents must be resolved or manually transferred. --- ## Field Mapping: SWSD Incidents → Ada Conversations If you do replay incidents as conversations, here is how the fields map: | SWSD Incident Field | Ada Field | Notes | |---|---|---| | `requester.email` | End User `profile.email` | Direct map | | `requester.name` | End User `profile.name` | Direct map | | `name` (incident title) | First message text or metadata | No direct "subject" field in Ada | | `description` | First conversation message body | Strip HTML | | `state` | `profile.metadata.swsd_state` | Store as metadata; no Ada state equivalent | | `priority` | `profile.metadata.swsd_priority` | Store as metadata | | `category` | Tag or metadata | No native category in Ada conversations | | `comments []` | Conversation messages | Map each comment as a message; preserve chronological order | | `created_at` | `profile.metadata.swsd_created_at` | Ada generates its own timestamps; store original for reference | | `custom_fields` | `profile.metadata.*` | String/integer/boolean only | | `assignee` | N/A | Ada uses AI agents, not assignee routing | | `due_date` / `sla` | N/A | No SLA concept in Ada | **What gets lost permanently:** Stateful lifecycle transitions and audit logs (who changed what, when). Incident-to-problem, incident-to-change, incident-to-asset relationships. Time-to-first-response and SLA breach data. Agent assignment history. If you need any of these for compliance, archive them in a separate data store before decommissioning SWSD. --- ## Migration Execution Plan ### Phase 1: Audit and archive (Week 1) - Classify every SWSD object into one bucket: `Ada knowledge`, `Ada live context`, `external archive`, or `do not migrate`. - Export all SWSD data via API: incidents, users, solutions, problems, changes, assets. - Archive non-migratable records to a data warehouse or cold storage. - Document custom fields, categories, sub-categories, and automation rules for reference during Ada configuration. - Audit user export for null email addresses (common in SAML/SSO tenants). - Document multilingual article inventory — count articles per language. - Validate data completeness against SWSD's built-in reports. - Assess GDPR/CCPA obligations for personal data being replicated into Ada. ### Phase 2: Ada configuration and knowledge import (Week 1–2) - Set up Ada AI agent profile, tone, and personality. - Configure knowledge sources and import SWSD solutions via Knowledge API. - Apply flat tag structure for SWSD category/sub-category hierarchy. - Curate recurring incident resolutions into additional knowledge articles. - Build Ada Processes for any multi-step workflows that previously existed as SWSD automations. - Set Coaching rules based on historical incident patterns and SLA escalation logic. - Configure channels (Chat, Email, Voice) per your support requirements. - Build the human escalation path — native handoff integration or custom Handoffs API implementation. - **Test knowledge indexing:** After loading articles, use Ada's Interactive Testing to verify generative answers are drawn from migrated content. Do not proceed to cutover if knowledge is not indexed. ### Phase 3: User and conversation migration (Week 2–3) - Create end users in Ada via End Users API, mapping SWSD requester records. - If replaying conversations: batch-create historical conversations from SWSD incidents. Respect the 24-hour auto-deletion window by pairing user creation with immediate conversation creation. - Throttle API calls to stay within Ada's rate limits (60,000/day, 300/minute for End Users and Conversations APIs). - Track migration progress in a state table: `{swsd_incident_id, ada_end_user_id, ada_conversation_id, status, created_at}`. - Set `language` field on End User records to match primary language of that user's SWSD history. ### Phase 4: Validation and cutover (Week 3–4) - Spot-check migrated data against source records. Verify message ordering, user attribution, and metadata accuracy. - Validate knowledge articles are indexed and generating correct AI responses via Ada's Interactive Testing. - Run a delta extraction from SWSD for any records created or updated after the initial extraction. SWSD supports filtering by `updated_at` on most endpoints — use `updated_at > [initial_extraction_timestamp]` to catch records that changed during migration. - Pilot one high-volume use case (password resets, order status) before full rollout. Measure answer quality, handoff rate, and knowledge gaps. - Decide on open-incident handling (hard cutover, parallel, or incident-by-incident). - Cut over by channel, not all at once. Route new conversations into Ada on the first live channel, keep SWSD history read-only, and only then retire the old intake path. - Keep SWSD in read-only mode for 30–90 days as a fallback reference. > [!TIP] > **Delta sync tip:** Run a final extraction filtering for `updated_at > [initial_extraction_timestamp]` just before cutover. Transform the delta payload and load it into Ada. This keeps your cutover window tight and prevents data loss from records modified during the migration. --- ## Common Failure Modes **HTML pollution.** Pushing raw SWSD HTML into Ada results in the AI generating responses with `
` and `` tags, or exhausting article token budgets with invisible markup. A typical SWSD article body carries 60–75% bloat when measured by character count before vs. after HTML stripping. **Broken images.** Failing to re-host SWSD's authenticated S3 images leaves Ada users with broken image icons. SWSD image URLs contain expiring signatures that become invalid after instance deprecation. **Internal data leaks.** Importing "Internal" SWSD documentation or private agent notes into a public-facing Ada bot. SWSD comments support private notes that are agent-only. Without a deliberate redaction step, teams leak internal language and one-off case details into the bot. **End user auto-deletion.** Pre-creating all end users before starting conversation imports. If the conversation import takes more than 24 hours, early users will be auto-deleted. Batch by user: create user → create their conversations → move to next user. **Duplicate conversations.** Ada's Conversations API has no idempotency mechanism. Your migration script must maintain its own deduplication state table, keyed on `swsd_incident_id`. **Rate limit exhaustion during bulk import.** With 60,000 requests/day and each incident requiring at minimum a user creation + conversation creation + one message = 3 API calls, you can process roughly 20,000 incidents per day. For 100,000 incidents, plan for 5+ days of import time. **Knowledge indexing lag.** Articles created via the Knowledge API are not available to generative answers instantly. Import knowledge at least 24 hours before go-live and verify via Interactive Testing before declaring cutover complete. **Wrong data in the wrong Ada field.** Conversation metadata does not act like a routing or answer variable. Oversized knowledge articles will be truncated or rejected at the 100KB limit. Attachment handling in Ada is designed for live handoff flows, not permanent storage. **Null emails from SSO tenants.** SWSD tenants using SAML-based SSO may have users with null or placeholder email fields. Ada's End Users API uses email for deduplication — null values cause unpredictable behavior. Audit and remediate before import. **Flattened taxonomy mismatch.** Attempting to preserve SWSD's hierarchical category/sub-category structure in Ada's flat tag model without a documented mapping convention. Establish compound tag naming rules before transformation begins. --- ## When to DIY vs. When to Get Help **You can likely handle this in-house if:** - You have fewer than 20,000 SWSD incidents to migrate - Your knowledge base has fewer than 500 articles - Your SWSD tenant is single-language - You don't need to preserve full conversation threading from incident comments - You have a developer comfortable with REST API scripting and can dedicate them for 2–3 weeks **You should consider a managed migration if:** - You have 50,000+ incidents with deep comment histories - You need to preserve attachments (requires external storage orchestration) - Your SWSD tenant has multilingual content requiring per-article language tagging - Compliance requirements mandate verifiable data completeness with audit trails - GDPR cross-border transfer obligations apply to your incident data - You need the migration completed in under 2 weeks - You are running Ada and SWSD in parallel during transition and need continuous sync - You need a custom handoff integration alongside the migration --- ## Making It Stick This migration is less about moving tickets and more about reshaping how your support operation works. SWSD is a human-agent workflow tool. Ada is an AI-first resolution engine. The technical migration gets your data across, but the real work is configuring Ada's AI agent, Processes, Coaching rules, and knowledge so it performs from day one. Prioritize the knowledge base transfer — it delivers the most immediate value and directly powers Ada's AI agent. Historical conversations provide context for human agents during handoffs but do not influence AI generative behavior. Archive everything from SWSD before you decommission it. Data you think you do not need today tends to surface in audits, legal requests, and edge-case debugging six months later. Keep CMDB, change, asset, and audit history out of the bot unless another system is owning them. Decide your open-incident strategy before cutover day, not during it. The absence of a clear policy on in-flight tickets is the most common cause of unplanned downtime in help desk migrations. > Moving from SolarWinds Service Desk to Ada? Our engineers will map your SWSD data model, handle the API extraction, manage Ada's rate limits, and deliver verified data in your new platform — with zero downtime. Book a 30-minute technical scoping call. > > [Talk to us](https://cal.com/clonepartner/meet?duration=30) ## Frequently asked questions ### Can I migrate SolarWinds Service Desk tickets directly into Ada? Not as a 1:1 historical import. Ada's Conversations API supports text-only messages with Ada-generated timestamps, so you lose chronological fidelity and attachment support. Most teams archive incidents and promote only curated resolutions into Ada as knowledge articles. ### What SolarWinds Service Desk data is lost when migrating to Ada? Problems, changes, releases, assets, CMDB relationships, SLA metrics, approval workflows, agent assignment history, and automation rules have no Ada equivalent. Incident attachments, rich-text formatting, and original timestamps are also lost or degraded. Export and archive this data before decommissioning SWSD. ### How long does a SolarWinds Service Desk to Ada migration take? A typical migration for 30,000–100,000 incidents takes 3–5 weeks including data mapping, knowledge import, test runs, and cutover. Smaller environments under 20,000 incidents can be completed in 2–3 weeks by a dedicated engineer. ### What are the API rate limits that affect this migration? SWSD Essentials allows 100 API calls/minute. Ada's Platform API defaults to 10,000 requests/day (100/minute, 10/second). The End Users and Conversations APIs allow up to 60,000 requests/day (300/minute, 30/second). Ada Knowledge supports up to 50,000 articles per AI Agent, 100KB per article, and 10MB per request. ### Should I migrate SWSD knowledge articles or incidents first? Knowledge articles first. They directly power Ada's AI agent and deliver immediate value. Import them via the Knowledge API at least 24 hours before go-live to allow indexing. Historical conversations provide context for human agents but do not influence AI agent behavior.