SAP Sales Cloud V2 Data Transfer Tool: The Step-by-Step Migration Guide

SAP’s Data Transfer Tool exists to solve one problem: moving your production data from Sales Cloud V1 (C4C) to Sales Cloud V2. It’s the official, SAP-supported migration path. And it works. But the documentation reads like it was written for people who already know how the tool operates.

We’ve run DTT migrations for multiple customers — from 50-user sales teams to 500+ user deployments with complex custom objects and deep S/4HANA integrations. This guide covers what the official docs leave out: the practical decisions, the errors you’ll hit, the validation steps that save you from a failed go-live, and realistic timelines based on actual project data.

TL;DR: SAP’s Data Transfer Tool (DTT) migrates master and transactional data from Sales/Service Cloud V1 to V2. Run the Readiness Check Tool (RCT) first — it identifies blockers before you start. DTT handles accounts, contacts, leads, opportunities, activities, and tickets automatically; custom objects, integrations, and workflow logic need manual rebuilding. A typical mid-market migration (100-200 users, 500K-2M records) takes 8-14 weeks end to end. Always run at least two full test migrations before production cutover. SAP significantly improved DTT in the 2508 and 2511 releases (SAP Community, 2025).

What Is the Data Transfer Tool (DTT)?

The Data Transfer Tool is SAP’s built-in utility for transferring business data from a V1 (C4C) tenant to a V2 tenant. It’s not a third-party add-on. It’s embedded in the V2 administration console, and SAP designed it to handle the structural differences between the two data models.

SAP introduced DTT alongside the V2 general availability push, then significantly improved it in the 2508 release (August 2025) and again in 2511 (November 2025). The 2508 release added support for custom business objects and improved error handling. The 2511 release expanded coverage to include email activities, notes with attachments, and better handling of cross-object references (SAP Community, 2025).

What DTT transfers:

• Accounts (corporate and individual)
• Contacts and their account relationships
• Leads and lead qualifications
• Opportunities with products, sales phases, and involved parties
• Activities (appointments, tasks, phone calls, emails)
• Service tickets and interactions
• Products and price lists
• Sales territories and organisational assignments
• Custom fields on standard objects
• Attachments and documents (with size limits)

What DTT does not transfer:

• Custom code logic (ABSL scripts, custom actions)
• Workflow rules and escalation configurations
• Integration configurations (communication arrangements, APIs)
• UI customisations (mashups, embedded content, custom UIs)
• Reports and analytics configurations
• User settings and personalisation
• Mail templates and merge fields

The distinction matters enormously. DTT handles the data. Everything else — the business logic, the integrations, the UI — needs to be rebuilt in V2’s architecture. For a broader view of what this means for your overall project, see our C4C to V2 migration strategy.

Prerequisites Before You Start

Before you touch the DTT, several things need to be in place. Skipping any of these creates problems downstream that cost more time than the preparation would have.

System requirements

• V2 tenant provisioned and activated. Your V2 environment must be live and accessible. This sounds obvious, but tenant provisioning can take 2-4 weeks through SAP’s process. Start early.
• V1 tenant on a supported release. DTT requires your V1 system to be on a minimum patch level. Check SAP Note 3350732 for the current minimum. If you’re behind, apply the patch first.
• Admin access to both tenants. The user running DTT needs full administrative rights in both the source (V1) and target (V2) systems. Partial access causes silent failures.
• Network connectivity. Both systems need to communicate. If your V1 tenant uses IP whitelisting or custom proxy configurations, ensure the V2 tenant’s IP ranges are permitted.

Run the Readiness Check Tool first

The Readiness Check Tool (RCT) is separate from the DTT but inseparable from the process. RCT analyses your V1 system and produces a compatibility report: which objects are ready for transfer, which need attention, and which are incompatible.

We consider RCT non-negotiable. Every DTT migration we’ve run starts with the readiness check. It catches problems that would otherwise surface mid-migration.

Data cleanup in V1

Your V1 data has accumulated years of inconsistencies. DTT will faithfully transfer those inconsistencies into V2 unless you clean up first.

• Duplicate accounts and contacts. Merge or flag duplicates before migration. V2’s deduplication capabilities are better, but migrating 3,000 duplicate records and then deduplicating is wasteful.
• Orphaned records. Contacts without accounts, activities without parent records, opportunities linked to deleted products. Find them. Fix them or remove them.
• Custom objects with no data. If a custom object has been empty for two years, it doesn’t need to migrate. Every object in the migration scope adds complexity.
• Inactive users. Review your user base. Migrate active users only. Reassign records from departed employees before migration, not after.

Gartner estimates that poor data quality costs organisations an average of $12.9 million per year (Gartner, 2021). Cleaning your data before migration is an investment, not a cost.

Step 1: Run the Readiness Check

Access the Readiness Check Tool from within your V1 administration panel under Administrator > Data Transfer > Readiness Check. On some V1 versions, it’s under Migration Tools.

What the RCT report tells you

The report scores your system across three dimensions:

Object compatibility. Each business object gets a status: Ready (green), Needs Attention (yellow), or Incompatible (red). Ready objects can transfer directly. “Needs Attention” objects have minor issues — usually field mapping gaps or data format differences. Incompatible objects require manual handling.

Data quality score. The report flags data quality issues: missing mandatory fields, broken references, orphaned records, and records exceeding V2 field length limits. A score below 70% means you need cleanup before proceeding.

Custom object assessment. Custom business objects are evaluated for V2 compatibility. Simple extensions (custom fields on standard objects) usually transfer cleanly. Complex custom objects with ABSL logic are flagged for manual rebuild.

How to interpret the scores

A perfect score is rare and not necessary. What matters is zero red items and an action plan for every yellow item. In our experience, a typical V1 system shows:

• 60-70% objects in green (ready)
• 25-35% in yellow (minor adjustments needed)
• 5-10% in red (manual rebuild required)

The red items are almost always custom code logic and complex integrations — things DTT was never designed to transfer. That’s expected, not alarming.

Document the RCT results. They become the foundation of your migration plan. Every yellow and red item needs an owner and a resolution date.

Step 2: Prepare Your V2 Environment

Your V2 tenant needs to be configured before receiving data. DTT transfers records, but it doesn’t create the business configuration to house them.

Tenant setup

• Organisational structure. Recreate your org structure in V2: sales organisations, territories, divisions. V2 uses a different assignment model, so this isn’t a copy — it’s a redesign.
• User provisioning. Create user accounts in V2 with appropriate roles. Map V1 user IDs to V2 user IDs — DTT uses this mapping to reassign record ownership.
• Business configuration. Set up lifecycle statuses, reason codes, sales phases, product categories, and other configuration data. These must exist in V2 before data arrives.

Custom fields mapping

V1 custom fields need explicit mapping to V2 extension fields. This is where most configuration time goes.

In V2, custom fields are created through the Key User Extensibility framework. The field types, lengths, and value helps may differ from V1. For every custom field in your migration scope:

1. Create the corresponding extension field in V2
2. Verify the data type matches (text, number, date, code list)
3. For code list fields, ensure all V1 values exist in the V2 value list
4. Document the V1 field ID to V2 field ID mapping

This mapping document is essential. DTT uses it during data transfer to route field values correctly. Errors here are the single most common source of migration failures.

For details on SAP Sales Cloud V2 capabilities and what V2’s extensibility looks like, see our solutions overview.

Step 3: Configure the DTT

With your V2 environment prepared, open the Data Transfer Tool from the V2 administration console: Settings > Migration > Data Transfer Tool.

Object selection

DTT presents a list of transferable objects. Select which objects to include in the migration. Our recommendation: start with master data, then transactional data.

Migration order matters. Objects with dependencies must transfer in sequence:

1. Products and price lists — referenced by opportunities and quotes
2. Accounts (corporate accounts first, then individual customers)
3. Contacts — linked to accounts
4. Leads — reference contacts and accounts
5. Opportunities — reference accounts, contacts, products
6. Activities — reference all of the above
7. Service tickets — reference accounts, contacts, products

DTT handles this sequencing automatically if you select all objects at once. But understanding the order helps when debugging: if opportunities fail, it’s often because an account reference didn’t transfer in an earlier batch.

Field mapping

DTT auto-maps standard fields between V1 and V2. For custom fields, you configure the mapping manually using the mapping document from Step 2.

The field mapping interface shows:

• Source field (V1): field name, data type, sample values
• Target field (V2): matched field or “Unmapped”
• Transformation rules: optional value conversion (e.g., V1 code “A001” maps to V2 code “ACTIVE”)

Review every mapping. Auto-mapped fields are usually correct, but we’ve seen cases where similarly named fields in V1 and V2 had different semantics. A field called “Category” in V1 might map to “Classification” in V2 — same concept, different field.

Transformation rules

For fields where V1 and V2 use different value sets, define transformation rules:

• Code list mappings. V1 status “In Process” becomes V2 status “In Progress”. Define every value pair.
• Field concatenation. V1 might split address into Street1 + Street2. V2 might combine them differently.
• Default values. V2 may have new mandatory fields that don’t exist in V1. Set default values to prevent null errors.
• Date format handling. Rarely an issue with SAP-to-SAP transfers, but validate timezone handling if your V1 and V2 tenants are in different regions.

Step 4: Run a Test Migration

Never run DTT against production data without at least one — preferably two — full test migrations. This is non-negotiable.

Dry run approach

1. Create a test V2 tenant or use the quality/staging environment. Never test against the production V2 instance.
2. Run DTT with full scope. Include all objects, all custom fields, all transformation rules. A partial test doesn’t validate cross-object references.
3. Use production-scale data. If production has 1 million records, don’t test with 10,000. Data volume creates different failure modes: timeout errors, memory limits, and performance bottlenecks that only appear at scale.
4. Measure execution time. Record how long each object type takes. This data determines your production cutover window.

Validation checks after test migration

After the test run completes:

Record count comparison. Compare source and target counts for every object type. Discrepancies indicate failed records.

Relationship integrity. Spot-check 50-100 records across object types. Verify that:

• Contacts are linked to the correct accounts
• Opportunities show the right products and sales phases
• Activities are associated with the right parent records
• Custom field values transferred correctly

Error log review. DTT generates a detailed error log. Every error needs classification: critical (blocks migration), major (data loss), or minor (cosmetic). Critical and major errors must be resolved before the production run.

Common test migration errors and fixes

Field length mismatch. A V1 text field allows 255 characters; the V2 equivalent allows 100. Records with values exceeding the V2 limit fail. Fix: either increase the V2 field length or add a transformation rule to truncate.

Lookup failures. A V1 opportunity references an account ID that doesn’t exist in V2. This happens when account records fail silently in an earlier batch. Fix: resolve the root cause (usually a data quality issue in V1) and re-run.

Duplicate key violations. V2 has stricter uniqueness constraints than V1. If V1 allowed duplicate external IDs, V2 will reject the second record. Fix: clean duplicates in V1 before migration.

Mandatory field nulls. V2 introduces new mandatory fields that don’t exist in V1. Records without values fail. Fix: add default values in the transformation rules.

Run the test migration, fix all errors, and run it again. We typically do 2-3 test cycles before the production run. Each cycle should produce fewer errors. If error counts aren’t decreasing, something systemic is wrong.

Step 5: Execute the Production Migration

Production migration is the culmination. By this point, you’ve already proven the process works through test runs. The production execution should be predictable.

Timing considerations

Weekend or low-traffic window. DTT puts load on both the V1 and V2 systems. Run during off-hours to minimise impact on active users. For European businesses, Friday evening to Sunday morning is the standard window.

Freeze period. Declare a data freeze on the V1 system before starting. No new records, no updates. Any changes made in V1 after the DTT snapshot are lost. Communicate this to all users at least one week in advance.

Duration planning. Use your test migration timing data, padded by 20-30%. If the test took 8 hours, plan for 10-12 hours for production. Network variability, larger record counts in production, and concurrent system load add time.

Monitoring progress

DTT provides a progress dashboard showing:

• Current phase (which object type is being transferred)
• Records processed vs. total
• Error count (running total)
• Estimated time remaining

Assign someone to monitor this continuously. If error rates spike above 2% for any object type, pause and investigate. It’s easier to fix a problem mid-migration than to clean up after a completed but flawed run.

Checkpoint strategy

For large migrations (1M+ records), consider a phased approach:

1. Phase A: Master data — accounts, contacts, products. Validate before proceeding.
2. Phase B: Opportunities and leads — depends on clean master data.
3. Phase C: Activities and tickets — highest volume, lowest risk if master data is solid.
4. Phase D: Attachments and documents — slowest transfer, network-intensive.

Each phase has a checkpoint. Validate counts and relationships before starting the next phase. If Phase B fails, you roll back Phase B without losing Phase A’s successful transfer.

Rollback strategy

DTT doesn’t have a one-click rollback. If the migration fails catastrophically:

• V1 is still intact. DTT reads from V1; it doesn’t modify the source. Your V1 system remains fully operational.
• V2 can be reset. For a clean restart, SAP can reset the V2 tenant to empty state. This requires a support ticket and takes 24-48 hours.
• Partial rollback. If only specific object types failed, you can delete the failed records in V2 and re-run DTT for those objects only.

The safest approach: keep V1 fully operational until V2 is validated and users have confirmed the migration is complete. We recommend a minimum 2-week parallel operation period.

Step 6: Post-Migration Validation

The migration is mechanically complete. Now you prove it.

Record count comparison

Run a full count comparison across all migrated object types. This is the same check from testing, but against production data. Anything that passed in test should pass in production. New discrepancies point to data created between the test run and the production freeze.

Relationship integrity checks

Deeper than counting. Validate that business relationships survived the transfer:

• Account hierarchies. Parent-child account structures are intact.
• Contact-to-account associations. No orphaned contacts.
• Opportunity pipeline. Sales phases, expected revenue, close dates, and product line items are correct.
• Activity timeline. Recent activities appear in the right chronological order on the right records.
• Custom field values. Spot-check 100+ records for each custom field to verify transformation rules worked.

User acceptance testing checklist

Before declaring success, have business users validate their own data:

• Sales managers: open their pipeline view, verify opportunity counts and values match
• Account executives: check their top 10 accounts for completeness
• Service agents: verify recent ticket history and customer interaction logs
• Admins: confirm territory assignments and user role mappings
• Reporting: run standard reports and compare totals to V1 baselines

UAT typically takes 3-5 business days. Don’t rush it. A user discovering missing data three months later is far more disruptive than spending an extra week validating now.

What the DTT Doesn’t Transfer

This section is critical. Understanding what DTT leaves behind determines the rest of your migration project scope and budget.

Custom code logic. V1 uses ABSL (ABAP Scripting Language) for custom business logic. V2 does not support ABSL. All custom logic must be re-implemented — either as V2 key user configurations or as BTP-based extensions. This is typically the largest manual effort in the migration.

Workflow rules. V1 workflows don’t transfer. Rebuild them in V2’s rule engine. The good news: V2’s rule engine is more capable. Many V1 workflows that required custom code can be built with configuration in V2.

Integration configurations. Communication arrangements, API endpoints, middleware connections, and SSO configurations are tenant-specific. Every integration needs to be re-established in V2. If your V1 system integrates with S/4HANA, marketing tools, or third-party services, plan for a full integration rebuild. See our CTI integration guide for what V2 integrations look like in practice.

UI customisations. Mashups, embedded HTML content, custom navigation entries, and side panels need rebuilding in V2’s UI framework. V2 uses a different side-by-side extension model via SAP Build Work Zone.

Reports and dashboards. V1 reports don’t transfer. Rebuild them using V2’s built-in analytics or SAP Analytics Cloud. Most customers find that V2’s native reporting covers 80% of what they built manually in V1.

Mail templates. Email templates with merge fields need to be recreated in V2’s template editor. The merge field syntax is different.

Budget for this. In a typical DTT migration project, the data transfer itself is 20-30% of the total effort. The remaining 70-80% is rebuilding the items above. For cost context, see our SAP Sales Cloud V2 pricing guide.

Common DTT Errors and How to Fix Them

Based on our migration projects, these are the errors you’ll encounter most frequently:

Keep a running error log. Categorise errors by severity and frequency. Some errors (like attachment size limits) affect a small number of records and can be handled individually post-migration. Others (like reference not found) indicate systemic problems that need root cause analysis.

Timeline: How Long Does DTT Migration Take?

Timelines vary by data volume, customisation complexity, and integration count. Here’s what we’ve seen across our projects:

By company size

These timelines cover the data migration workstream only. The total V1-to-V2 project — including integration rebuilds, custom logic re-implementation, training, and go-live — is longer. For a full picture of the overall strategy, see our V1 to V2 migration comparison.

Planning table

Use this as a starting framework for your project plan:

Pad every estimate by 20%. In our experience, the data cleanup and field mapping phases are the most likely to overrun. Nobody knows the true state of their V1 data until they look.

FAQ

Does DTT support delta migration?

Yes, with caveats. DTT can run incrementally to transfer records created or modified after the initial migration. This is useful for the period between your test migration and production cutover. However, delta migration doesn’t handle deletions — records deleted in V1 after the initial transfer remain in V2. Plan a cleanup pass after cutover.

Can I run DTT multiple times?

Yes. DTT is designed for iterative execution. Each run can be scoped to specific object types or filtered by date range. Subsequent runs skip already-transferred records (identified by unique keys). This is how the test-and-refine cycle works.

Does DTT work for Service Cloud V1 to V2 migration?

Yes. DTT covers both Sales Cloud and Service Cloud objects. Service tickets, interactions, knowledge articles, and SLA configurations are within DTT’s scope. The process is identical — RCT first, then DTT configuration, test runs, and production migration.

What happens to my V1 system after migration?

Nothing. V1 remains fully operational. SAP recommends maintaining V1 access for a minimum of 90 days after V2 go-live for reference and audit purposes. Eventually, the V1 tenant is decommissioned, but that’s a separate process on your timeline.

Can I migrate from a third-party CRM to V2 using DTT?

No. DTT is exclusively for SAP V1-to-V2 migration. If you’re migrating from Salesforce, Dynamics 365, or another CRM, you’ll use SAP’s standard data import APIs or a middleware solution. We’ve published a separate guide on Excel-to-V2 migration for simpler scenarios.

How do I handle custom objects with complex relationships?

Custom objects with simple structures (custom fields on standard objects) transfer through DTT. Complex custom business objects with inter-object relationships, ABSL logic, or custom UIs need manual rebuild. Export the data from V1 via OData, transform it, and import into V2 via V2’s APIs. This is project work, not DTT work.

What if my V1 system has heavy customisation?

Heavy customisation means more manual rebuild effort, but it doesn’t disqualify you from using DTT. DTT handles the data; your project team handles the logic. The RCT report quantifies exactly how much customisation sits outside DTT’s scope. Use that report to scope and budget the manual workstreams.

Is there a maximum data volume for DTT?

SAP doesn’t publish a hard limit. We’ve successfully migrated tenants with 10M+ records across all object types. Performance is the practical constraint: very large datasets take longer and may require batch size tuning. The 2511 release improved DTT’s performance for high-volume scenarios significantly.

Migrating from V1 to V2 is not optional for organisations invested in SAP’s CRM ecosystem. The Data Transfer Tool makes the data portion manageable. What separates a smooth migration from a painful one is preparation: clean data, complete field mapping, thorough testing, and realistic timelines.

If you’re planning a DTT migration and want a second opinion on your readiness, get in touch. We’ve been through this enough times to know where the problems hide.