Migration Checklist: Moving to Salesforce Service Cloud

Phase 0

Decide & Plan

Lock scope, owner, success criteria, and cutover window before any work starts.

• Define migration scope by Service Cloud object. Document explicitly which standard objects are in scope (Account, Contact, Case, CaseComment, EmailMessage, ContentVersion, Knowledge__kav, Entitlement, ServiceContract, LiveChatTranscript, MessagingSession, OmniChannel routing config) and which custom objects from the source map to which destination object.

  Risk if skipped: Scope ambiguity surfaces mid-cutover as missing channels or article history, forcing emergency re-imports against governor limits.

• Define ticket-history scope and cut-off date. Decide how many years of closed Cases and their CaseComment / EmailMessage threads move over. Decide whether chat transcripts, voice call logs, and in-app messaging sessions are in or out. Decide whether attachments are in or out.

  Risk if skipped: An unbounded historical scope inflates File Storage, breaks the cutover window, and forces a paid storage add-on at short notice.

• Identify the Salesforce edition and storage profile. Confirm Enterprise vs. Unlimited Service Cloud licensing, check current Data Storage and File Storage allocations against projected post-migration usage, and confirm Knowledge license counts for read and author seats.

  Risk if skipped: Hitting storage caps mid-load aborts bulk load jobs and stalls Knowledge article publication.

• Decide channel scope in writing. List which channels the destination will accept on day one: Email-to-Case, Web-to-Case, Service Cloud Voice on Amazon Connect or a partner telephony adapter, Chat via LiveChatTranscript, Messaging for In-App and Web via MessagingSession, Social Customer Service. Out-of-scope channels do not migrate transcripts.

  Risk if skipped: Quietly migrating a channel whose runtime is not configured leaves transcripts orphaned in the destination.

• Document legal and residency constraints. Confirm whether the org must run on Hyperforce in an EU region for GDPR, capture SOC2/HIPAA evidence requirements, and document any data-retention policies that change at cutover.

  Risk if skipped: Residency violations discovered after go-live require a Hyperforce region migration and DPA renegotiation.

• Assign a single accountable DRI and a stakeholder map. Name one decision-maker for scope changes, plus a RACI covering Support Operations, Support Leadership, IT, Telephony, Security, and Legal.
• Define written success criteria. Specify the exact conditions that must hold before sign-off: per-object record-count parity, aggregate open-case count match, sample-record field-by-field accuracy at Y%, Knowledge article publication counts, and zero open critical UAT defects.

  Risk if skipped: Without falsifiable criteria, the sponsor declares the project done while critical history gaps persist.

• Set the cutover window and source-system freeze date. Pick a specific date and time, the freeze hour for source-system writes, and the planned read-only date for the legacy system.
• Document out-of-scope items explicitly. List the data, automations, integrations, and channels that will not move, so they are not raised as defects later.
• Estimate load throughput and storage consumption against the cutover window. Project record volume by object, factor in test runs and re-loads, and confirm the org fits within available storage and load throughput budgets. Knowledge article load is sequential because every version must be published in order.

  Risk if skipped: Cumulative consumption from sandbox tests, Knowledge re-versioning, and reloads can exhaust the budget hours before cutover finishes.

Phase 1

Pre-Migration Prep

Clean the source, stand up the destination, and prep people before the first export.

Phase 2

Source Export

Pull every byte you will need, with the exact timestamp captured for delta reconciliation.

• Export Accounts (or source companies) with every standard and custom field as UTF-8 CSV. Include the source primary key column so it can populate Account.Legacy_Id__c as External ID.

  Risk if skipped: Missing the source primary key forces fuzzy matching downstream and reintroduces duplicates.

• Export Contacts (or source end-users) with every field. Include the source Account-FK column so the loader can wire Contact.AccountId via External ID.
• Export Cases (or source tickets) with every standard and custom field as UTF-8 CSV. Capture Status, Origin, Priority, Reason, OwnerId-equivalent, AccountId-equivalent, ContactId-equivalent, source primary key, original CreatedDate, ClosedDate, first-response timestamp, resolution timestamp, SLA status, and CSAT score.

  Risk if skipped: Missing Subject, Status, or Origin blocks Case insert because these are required.

• Export public ticket comments as a separate CaseComment CSV. Each row maps to a CaseComment with CommentBody (4,000 char limit), IsPublished=true for public replies, and ParentId pointing to the parent Case External ID. Preserve original CreatedDate and CreatedById equivalents.

  Risk if skipped: Truncated CommentBody silently drops the tail of long agent replies.

• Export internal notes as a separate CaseComment CSV with IsPublished=false. Mark these as internal so they never become customer-visible on the destination feed.
• Export email correspondence as a separate EmailMessage CSV. Each row maps to EmailMessage with ParentId pointing at the Case External ID, MessageDate carrying the original send timestamp, HtmlBody and TextBody, Incoming flag, FromAddress, ToAddress, CcAddress, BccAddress, and Subject. Sort by MessageDate so thread order is preserved on load.

  Risk if skipped: Missing MessageDate causes EmailMessages to sort by load time on the case feed, scrambling the thread.

• Export inline image and attachment metadata referenced inside email HTML. Capture each Content-ID so the loader can rewrite cid: references to ContentVersion download URLs after binaries land.

  Risk if skipped: Unrewritten cid: links render as broken images in the migrated case feed.

• Export Knowledge articles with full version history per article. For every article, pull every version in sequence. Lightning Knowledge stores articles as Knowledge__kav records that require sequential insertion through Salesforce's Knowledge load path.

  Risk if skipped: Missing intermediate versions breaks the rebuild because version N cannot be inserted without version N-1.

• Export article-to-category and article-to-data-category-group mappings. These drive Knowledge navigation and visibility filters; without them, articles publish without categorization.
• Export attachment binaries plus a metadata sidecar. The sidecar maps each file to its parent Case, Contact, or Knowledge__kav source key and captures original filename, file size, and upload timestamp.
• Export Chat transcripts as a LiveChatTranscript CSV. Capture transcript body, start time, end time, agent identifier, visitor identifier, and parent Case source key where one was created.
• Export Messaging sessions as a MessagingSession CSV. Capture the message thread, channel identifier, end-user identifier, status, and timestamps.
• Export Service Cloud Voice call logs. Capture call recording URL, call start and end timestamps, agent identifier, caller phone number, and parent Case source key. Confirm call-recording retention with the telephony vendor before export.
• Export the user list with role hierarchy and Profile assignments. Capture email, alias, ProfileName, RoleName, manager, and active status so Salesforce users can be mapped to source agents.
• Export source SLA policy definitions, business hours, and holiday calendars. These become the source side of the Entitlement + MilestoneType + BusinessHours rebuild in Phase 3.
• Capture screenshots and exports of source automations, reports, and dashboards. These do not transfer; the screenshots seed the rebuild list in Phase 7.
• Record the exact UTC timestamp of every export. This defines the delta window for the Phase 5 final pull.

  Risk if skipped: Without timestamps, the delta cannot be computed and last-minute source edits are lost.

Phase 3

Transform & Map

Reshape source CSVs into Service Cloud-shaped files, with every picklist, channel, and thread relationship resolved.

Phase 4

Sandbox Test Migration

Catch every defect in a sandbox before it costs real records in production.

• Refresh the Full or Partial Copy Sandbox immediately before the test run. A stale sandbox lacks the latest metadata changes from Phase 1b and will not reflect production load behavior.

  Risk if skipped: Testing against stale metadata hides field-level-security and Validation Rule defects.

• Load a 1–5% representative sample of each object via Data Loader. Data Loader auto-chunks into batches. Use Workbench for ad-hoc small loads. Load Knowledge__kav via the dedicated Knowledge load path.
• Spot-check 10 random sandbox Cases field-by-field against source. Verify Subject, Status, Origin, Priority, custom fields, Owner, AccountId, ContactId, CreatedDate.

  Risk if skipped: Sampling fewer than 10 misses encoding and transformation bugs that affect 1% of rows.

• Test CaseComment thread reassembly on a sample of 25 Cases. Confirm public comments (IsPublished=true) and internal notes (IsPublished=false) are visible in the correct sections of the agent console and ordered by CreatedDate.

  Risk if skipped: A misset IsPublished flag exposes internal notes to customers in the Experience Cloud portal.

• Test EmailMessage threading and ordering on a sample of 25 Cases. Confirm every email lands with ParentId resolved, MessageDate populated, and the case feed renders the thread top-to-bottom in source order.

  Risk if skipped: Out-of-order EmailMessages scramble customer dialogue and confuse triage agents post-cutover.

• Test cid: inline image rewriting on EmailMessage HTML bodies. Open 10 sample emails in the case feed and confirm every embedded image renders.

  Risk if skipped: Broken inline images surface as user-reported defects in week one.

• Run a Knowledge article version replay against the sandbox. Load one article with at least three historical versions and confirm each draft → published transition succeeded via PublishingService.publishArticle. Verify only one version is published at the end.

  Risk if skipped: Version replay misordering breaks the published article history irreversibly.

• Test Entitlement assignment on a sample of open and closed Cases. Confirm open cases attach to the right Entitlement and trigger MilestoneInstance creation; confirm closed cases carry Legacy_First_Response_At__c and Legacy_Resolution_At__c without firing milestone clocks.

  Risk if skipped: If active Entitlement Processes start re-clocking historical cases, every closed case shows as breached.

• Specifically test long strings, special characters, NULL, and Unicode emoji. Load a fixture row that exercises maximum-length CommentBody, embedded quotes, embedded newlines, leading/trailing whitespace, NULL, and 4-byte UTF-8 characters in EmailMessage bodies.

  Risk if skipped: Unicode astral characters silently truncate and corrupt customer names and message text.

• Test relationship preservation via External ID lookups. Confirm Case.AccountId, Case.ContactId, CaseComment.ParentId, EmailMessage.ParentId, and ContentVersion-to-parent links all wire to the correct record.

  Risk if skipped: Lookup-by-external-ID failures point comments and emails at the wrong case and corrupt the entire thread hierarchy.

• Confirm the 'Set Audit Fields' strategy actually preserved CreatedDate. Inspect a sample of sandbox Cases and CaseComments via SOQL to verify CreatedDate matches the source timestamp, not the load timestamp.
• Run a Validation Rule and Apex Trigger fire-pattern audit during the test load. Use the Bulk Data Load Jobs setup page to confirm rules fired or were bypassed as designed; review any per-row errors emitted by Triggers.

  Risk if skipped: A Trigger firing on insert can exceed the 150 DML statement governor limit and abort a batch partway.

• Test ContentVersion attachment upload and email cid: rewrite pass. Confirm files arrive, parent-record links resolve, File Storage consumption matches projection, and cid: references in EmailMessage HtmlBody now point at ContentDocument URLs.
• Test Chat, Messaging, and Voice channels end-to-end. Trigger a test chat, a test in-app message, and a test inbound call into the sandbox. Confirm LiveChatTranscript, MessagingSession, and call records land and route through Omni-Channel.
• Run a full-volume rehearsal in the Full Sandbox. Load every record at production volume. Time each step end-to-end. Knowledge version replay is the slowest object — measure articles per hour.

  Risk if skipped: Skipping volume rehearsal hides Knowledge load throughput issues that only appear at full scale.

• Extrapolate sandbox timing to the production window. Multiply by 1.5x for safety margin. If the projection exceeds the cutover window, re-plan before Phase 5.
• Have 2–3 Support Operations domain experts spot-check the sandbox data. Pick known recent cases and a sample of Knowledge articles; ask the expert whether everything looks right at the record and thread level.
• Document every defect with the failing row, the rule that rejected it, and the fix. Maintain a defect ledger; close each defect before sign-off.
• Obtain written sandbox sign-off before scheduling production cutover. Sponsor + support-ops lead must sign.

  Risk if skipped: Proceeding to production without sign-off transfers all sandbox defects into the live org.

Phase 5

Production Cutover

The tightly-sequenced execution window. Idempotent loads, dependency order, and visible row counts.

• Confirm the source-system freeze is in effect. Query source audit logs to verify no writes in the last 60 minutes before pulling the final export.

  Risk if skipped: Writes after the freeze produce a silent delta that never reaches the destination.

• Pull the final source export with timestamps. Capture the delta from the Phase 2 baseline plus any rows whose source CreatedDate or LastModifiedDate falls in the gap window.
• Disable Workflow Rules, Process Builder flows, Flows, and active Triggers on Case insert. Either deactivate at the rule level or route every load through the bypass-condition pattern created in Phase 1b. Pay specific attention to auto-acknowledgement email rules.

  Risk if skipped: Active auto-response rules send thousands of false acknowledgement emails to customers during the load.

• Disable Duplicate Rule blocking; leave matching in 'Report' mode. Re-enable blocking after Phase 6 reconciliation finishes.
• Disable Entitlement Processes on Case insert. If an Entitlement Process is active on insert, every backdated migrated case will fire milestone clocks. Activate Entitlement Processes only after all closed cases are loaded.

  Risk if skipped: Active Entitlement Processes during load create false MilestoneInstance breach records on every historical case.

• Load Users first, then Accounts, then Contacts. Use upsert keyed on the External ID field per object so reruns are idempotent.

  Risk if skipped: Loading Contacts before their parent Accounts orphans the children and forces a delete-and-reload.

• Load Knowledge articles via sequential version replay. For every article, insert v1 as draft → publish → create draft v2 → publish → repeat. Use PublishingService.publishArticle per version. This is the slowest object; start it early in the window.

  Risk if skipped: Parallel version inserts fail; running them serially is the only supported pattern.

• Load Entitlements, ServiceContracts, and link to Account. Required before Cases land so each Case can reference the right Entitlement.
• Load Cases via upsert, keyed on Legacy_Case_Id__c. Populate Legacy_First_Response_At__c, Legacy_Resolution_At__c, Legacy_SLA_Status__c, Legacy_CSAT_Score__c at this step.
• Load CaseComments (public and internal). ParentId references Case.Legacy_Case_Id__c via External ID. Maintain IsPublished flag per row.

  Risk if skipped: A misset IsPublished flag exposes internal notes to customers in any Experience Cloud portal.

• Load EmailMessages, sorted by MessageDate. ParentId references Case External ID. Incoming flag set per row. MessageDate carries the original timestamp.
• Load ContentVersion binaries and link to parent Case, Contact, or Knowledge__kav. These consume the most File Storage; monitor consumption per batch.
• Run the cid: inline image rewrite pass on EmailMessage HtmlBody. Now that ContentVersion records exist, update each HtmlBody to point at the destination ContentDocument download URL.

  Risk if skipped: Skipping this pass leaves every inline image broken on the migrated case feed.

• Load LiveChatTranscript, MessagingSession, and Service Cloud Voice call records. Each references the parent Case via External ID. Confirm Chat deployment and Messaging Channel records exist.
• Capture bulk load job IDs, row counts, and error files for every load step. Persist these to a runbook log; they are evidence for audit and the basis for Phase 6 reconciliation.

  Risk if skipped: Without job IDs, error rows cannot be retrieved from the Bulk Data Load Jobs page after the retention window expires.

• Cross-check destination row count vs. source row count after every load. Variance above 0 must be investigated before moving to the next object.

  Risk if skipped: Continuing past a variance compounds errors and makes root-cause analysis impossible.

• On any partial failure, stop and diagnose before re-running. Idempotent External ID upserts let you fix the transform and re-run the same file without duplicates.
• Re-enable Validation Rules, Triggers, Workflow Rules, Flows, Entitlement Processes, and Duplicate Rule blocking. Verify each is back to its production state before opening the org to agents.
• Activate Email-to-Case, Web-to-Case, Service Cloud Voice, Chat, and Messaging deployments. These were paused in Phase 1b; bring them online now so new customer traffic lands correctly.
• Run a smoke test as 3 representative user Profiles. Log in as a Service Agent, a Supervisor, and an Admin; confirm Case console, Omni-Channel acceptance, Knowledge search, and Macros behave as designed.

Phase 6

Validate

Prove the migration was correct before opening the org to agents.

Phase 7

Post-Migration Cleanup

Hand the org to its operators, decommission the source, and capture lessons learned.

• Announce go-live to all agents with login URL and the first-responder contact. Include a one-page quick-start covering the Lightning Service Console, Omni-Channel acceptance, and Knowledge search.
• Run role-segmented training sessions for agents, supervisors, and Knowledge authors. Cover Case feed, Macros and Quick Actions, Knowledge insertion into email, Omni-Channel routing, and Voice/Chat/Messaging accept flow.
• Set the source system to read-only on the announced date. Block writes but keep reads available for the documented retention period.

  Risk if skipped: Leaving the source writable encourages agents to keep working in the old system, fracturing the source of truth.

• Rebuild reports and dashboards in Salesforce. Reports do not transfer; use the Phase 2 screenshots as a build list. Prioritize: SLA attainment, CSAT trend, agent workload, case backlog by Status, first-response time.
• Activate Entitlement Processes for new cases going forward. Confirm new cases created post-cutover attach to the right Entitlement and fire milestone clocks. Historical cases continue to use the Legacy_* custom fields and do not retro-fire.

  Risk if skipped: Skipping activation leaves new cases without SLA tracking on day one.

• Rebuild remaining automations: Flows, Assignment Rules, Auto-Response Rules, Approval Processes. These do not transfer; reconstruct from the Phase 2 capture. Test each against migrated cases before activation.

  Risk if skipped: Activating untested Flows on top of migrated data can mass-update or mass-email customers.

• Re-establish integrations: telephony, BI tools, knowledge sync, ticket-bot connectors. Re-authenticate, point at production, and run a smoke test per integration.
• Re-enable Duplicate Rules in blocking mode. Confirm matching keys still resolve to a single record per entity and that the Duplicate Job report runs clean.
• Configure Sharing Rules, Role Hierarchy, and Permission Set assignments per support role. Confirm record visibility for each Profile against the agreed access matrix; pay specific attention to Knowledge visibility via Data Categories.

  Risk if skipped: Over-permissive Sharing Rules expose case data to the wrong team; under-permissive rules block agents from their own queues.

• Schedule a 30-day post-migration retrospective with the project team. Capture what went well, what surprised the team, and what to change for the next migration.
• Document the source-system decommission date. Typically 90 days after cutover, after the final retention window. Confirm with Legal and Finance.
• Archive source-system exports and bulk load job logs to long-term storage. Encrypt at rest, restrict access, and document retention per the policies captured in Phase 0.

  Risk if skipped: Without retained exports, a forensic question six months in cannot be answered.

• Close the migration project formally with a final status report. Include: tasks completed, deferred items, final defect count, sign-off list, and a recommended day-30 checklist for the support operations team.