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

SAP’s Data Transfer Tool (DTT) moves business data and configuration from SAP Cloud for Customer (C4C, “V1”) to SAP Sales Cloud and Service Cloud Version 2. It is SAP’s own tool, supported by SAP, and it improves with almost every quarterly release. What the documentation cannot give you is the project around it: the order of work, the preparation, the test cycles and the decisions that nobody else can make for you.

This guide covers that project. It follows the sequence we use in V1-to-V2 work: readiness check, cleanup, V2 preparation, test transfers, production cutover and validation. Where a statement describes SAP’s tool, it links to SAP’s documentation. Where it describes how we plan, it says so.

TL;DR: DTT runs in your V1 tenant (Transition work center) and is activated by SAP on request. Run the Readiness Check first, clean up V1 (DTT does not filter records), and prepare an empty V2 tenant with the configuration each object needs. Then run at least two full test transfers, cut over in a planned freeze window and use delta mode for the gap. DTT handles the data; custom logic, integrations, UI extensions and reports are rebuilt in V2. The DTT data workstream for a mid-sized tenant typically takes 8 to 14 weeks in our planning.

What is the Data Transfer Tool (DTT)?

DTT is the transfer part of SAP’s transition toolset for moving from V1 to V2. The other part is the Readiness Check Tool (RCT), which analyses your V1 tenant before anything moves. Both live in the Transition work center of the V1 system (SAP Help: Data Transfer Tool; SAP Help: Readiness Check Tool).

DTT transfers data object by object. For each supported object, SAP ships a template with the field mapping, transformation logic and load validation. The tool also handles the sequence between dependent objects and writes logs and error messages you can work with.

The scope has grown steadily. Some of the changes SAP has announced in its release briefings:

• 2508 (August 2025): Test Data Transfer with “Data Only” as the default, a Transfer History for monitoring, new objects such as Territories and Competitor Products, and support for Notes, Product Group External IDs and further extension fields.
• 2511 (November 2025): the business configuration load can be separated from the business data transfer, new prerequisite checks (for example, scoped services in V2) and more detailed error messages (SAP Community: 2511 release briefing).
• 2602 (February 2026): Visits, Route Planning and Account Hierarchy as transferable objects, and the transfer of PDI field data moved from beta to general availability (SAP Community: 2602 pre-release briefing).
• 2605 (May 2026): a count summary for organisational structures, transfer of key user extensibility fields on business partner relationships, and code list mappings as part of “Transfer All BC” (SAP Community: 2605 pre-release briefing).

Because the list changes every quarter, check the object list on the SAP Help page at the start of your project, not against a blog post (this one included).

What DTT typically covers: accounts, contacts, individual customers, leads, opportunities, activities (appointments, tasks, phone calls), tickets, products and related master data, territories, organisational structures, notes and attachments, and extension fields where the mapping is complete.

What DTT does not cover:

• Custom logic from the V1 SDK (PDI/ABSL scripts, custom business objects with their own behaviour)
• Workflow rules and notifications
• Integration scenarios with ERP and third-party systems
• UI adaptations and mashups
• Reports and dashboards
• Personal settings and email templates

That split defines the project. DTT moves the data. Everything else is rebuilt in V2’s architecture. For the strategic side of that decision, read our C4C to V2 migration strategy and our assessment of V2’s current limitations. If you want a fixed-price first step, our V1 to V2 migration readiness assessment checks your landscape in 3 days for CHF 7’500, credited against the V2 implementation.

Prerequisites before you start

Access and tenants

• Request DTT from SAP. SAP activates the tool per customer. Open a case on component LOD-LE-MIG-CNS and include the URL of your V2 tenant.
• Assign the Transition work center. In V1, add the Transition work center to the business role of the administrators who will run the readiness check and the transfer.
• Provision the V2 tenant early. SAP’s guidance is that the target V2 tenant should be in an empty state, without business data. Do not let anyone “try things out” in the tenant you plan to load. Use a separate tenant for prototyping.
• Check each object’s prerequisites. Some configuration must exist in V2 before the transfer, for example case types for tickets. SAP documents these per object; read those pages before planning, not during the first test run.

Run the Readiness Check first

The Readiness Check Tool analyses your V1 tenant and shows which standard objects you use, data volumes per object, custom fields, PDI solutions, mashups and embedded components, and the items SAP classifies as transition blockers. Recent releases added attachment volumes per object and a list of installed add-ons.

We treat the readiness check as the start of every V1-to-V2 project. It is the first factual answer to “how much of our system moves automatically, and how much do we rebuild?”

Clean up V1 before you transfer

DTT does not let you pick a subset of records per object. Whatever sits in V1 moves. So the cleanup has to happen in V1:

• Duplicates. Merge duplicate accounts and contacts in V1. V2 has a configurable duplicate check, but it is designed for new records, not for sorting out thousands of migrated ones.
• Orphaned records. Contacts without accounts, activities without a parent, opportunities pointing to discontinued products. Fix them or archive them.
• Obsolete custom fields. A field nobody has filled in for two years does not need an extension field in V2. Every field in scope needs a mapping and a test.
• Departed users. Reassign records owned by people who have left before the transfer, not afterwards.

This is also the moment to decide what “good data” means for your V2 system. Our post on CRM data quality as the foundation for AI covers the rules we use.

Step 1: Read the readiness check properly

Open the Readiness Check in the Transition work center of V1 and run it against your production tenant. Then go through the results by category:

Standard objects and volumes. Which objects are in use, and how many records each holds. Volume drives the duration of the test and production runs.

Customer-specific extensions. Custom fields, PDI solutions, mashups and embedded components. This list is the backlog for your rebuild workstreams: some items become V2 extension fields, some become side-by-side extensions on SAP Business AI Platform (BAIP, formerly BTP), and some are dropped.

Transition blockers. Items that prevent an automatic transfer. Each one needs an owner and a decision.

Turn the output into a migration plan: every object in scope, its prerequisites in V2, its mapping status and who signs off the result. That document is your plan for the next weeks.

Step 2: Prepare the V2 tenant

DTT transfers records. It does not design your V2 system.

Organisation and users

• Organisational structure. Sales and service organisations, units and territories. V2 uses its own model; treat this as a design step, not a copy.
• Users and roles. Create users and business roles in V2 so that record ownership can be assigned during the transfer.
• Business configuration. Sales cycles and phases, status and reason codes, product categories and the other settings that transferred data refers to. Since 2511, the configuration load and the data load can run separately, which makes it easier to settle configuration first.

Extension fields and code lists

Custom fields from V1 need a target in V2. In V2 they are created as extension fields through key user extensibility. For every field in scope:

1. Create the extension field in V2 with a matching data type
2. For code list fields, make sure every value used in V1 exists in V2 or has a mapping
3. Record the V1 field and the V2 target in your mapping document
4. Test it in the first transfer run

Incomplete mappings are the most common reason for rejected records in test runs. Extension fields, notes and attachments only transfer when the mapping for the business object is complete.

For an overview of what V2 offers out of the box, see our SAP Sales Cloud V2 solution page.

Step 3: Configure the transfer

In the Transition work center, DTT lists the objects available for transfer. Start with master data, then transactional data. DTT applies its own sequencing logic between dependent objects, but you need to understand the dependencies to read the logs:

1. Organisational structure, territories, products
2. Accounts and individual customers
3. Contacts and relationships
4. Leads
5. Opportunities
6. Activities (appointments, tasks, phone calls, visits)
7. Tickets

If opportunities fail, the cause often sits one level up: an account that did not transfer, a product that does not exist in V2 or a missing code list value.

Review the delivered mapping templates object by object. The standard fields are mapped by SAP. Your job is the customer-specific part: extension fields, code list values and the fields whose meaning changed in your V1 usage over the years. A field called “Category” can mean three different things in three sales units.

Step 4: Run test transfers

Never run the production transfer without at least one, better two, complete test runs.

How to test

1. Use a V2 test tenant that is empty and prepared exactly like production. Never test against the tenant you will go live with.
2. Transfer the full scope. All objects, all extension fields. A partial test does not show the problems in cross-object references.
3. Use production volumes. A small sample hides the problems that only appear at scale: long runtimes, large attachments, rare code list values.
4. Measure the runtime per object. These numbers define your cutover window.

What to check after each run

Counts. Compare the number of records per object in V1 and V2. The Transfer History and the count summaries help; for important objects, also count independently.

Object	V1	V2	Difference	Action
Accounts	12’450	12’450	0	OK
Contacts	34’200	34’187	-13	Check log
Opportunities	8’930	8’930	0	OK
Activities	156’000	155’842	-158	Check log

Illustrative example, not customer data.

Relationships. Spot-check 50 to 100 records across objects: are contacts linked to the right accounts, do opportunities show the right products and phases, are activities attached to the right parent records, did extension field values arrive?

Error log. Classify every error: blocking, data loss or cosmetic. Blocking errors and data loss are fixed before the next run.

Typical error categories

Category	Typical cause	What to do
Missing reference	A parent record (account, product) did not transfer or does not exist in V2	Fix the parent object first, then rerun the dependent object
Code list value unknown	A V1 value has no counterpart in V2	Add the value in V2 or map it to an existing one
Mandatory field empty	V2 requires a value that V1 never had	Set a default in the mapping or fill the field in V1 before the transfer
Extension field not transferred	Mapping for the business object incomplete	Complete the mapping; rerun the object
Missing V2 configuration	Prerequisite not created (for example case types)	Create the configuration in V2; the prerequisite checks since 2511 flag many of these
Duplicates	V1 contains the same customer several times	Merge in V1 before the next run
Large attachments	Files exceed size limits or slow the run down	Check attachment volumes in the readiness check; archive or move very large files separately

The exact messages are in the DTT log; since 2511, SAP shows the error type in more detail. Plan two to three test cycles. Each cycle should produce fewer errors. If the numbers do not go down, something systematic is wrong: usually in the mapping or in V1 data quality.

Step 5: Run the production transfer

By now the process should hold no surprises. The production run repeats what the test runs have proven.

Timing

Choose a quiet window. The transfer loads both systems. A weekend is the usual choice for companies in Switzerland and Germany.

Freeze V1. Announce a change freeze in V1 at least a week in advance. Anything changed in V1 after the snapshot has to come over through delta mode or is lost.

Plan the duration with a buffer. Take the runtime of the last test run and add 20 to 30 percent. Production volumes are higher and the systems are under different load.

Monitor the run

Assign one person to watch the transfer continuously, using the Transfer History and the logs. If an object shows an unusual number of errors, stop and investigate. A problem found mid-run is cheaper than a completed but flawed transfer.

Use checkpoints for large tenants

For tenants with more than a million records, split the run into phases and validate after each one:

1. Master data: organisational structure, products, accounts, contacts
2. Sales documents: leads and opportunities
3. Activities and tickets: the largest volumes
4. Attachments: the slowest part

Plan the fallback

DTT reads from V1 and does not change the source. If the production transfer fails, V1 is still intact and users can continue working there. Because V2 should be empty before the transfer, a restart means cleaning up the V2 tenant. Agree with SAP in advance how a reset would work, and build that time into your plan. Keep V1 available until V2 is validated and signed off.

Step 6: Validate after cutover

Counts and delta

Repeat the count comparison against production data. Any new difference points to records created or changed between the last test run and the freeze. Run the delta transfer for these objects.

Business relationships

• Account hierarchies are complete
• Contacts are assigned to the right accounts
• Pipeline: phases, expected values, close dates and products are correct
• Activity history appears in the right order on the right records
• Extension fields carry the right values (spot-check at least 100 records per important field)

Acceptance by the business

Before you declare success, let users check their own data:

• Sales managers: pipeline view, number and value of opportunities
• Account managers: their ten most important accounts
• Service agents: recent tickets and customer history
• Administrators: territories, roles and assignments
• Reporting: key figures compared with V1

Plan three to five working days. A user who discovers missing data three months later costs far more than an extra week of checking now.

What the project has to rebuild

The data is the part DTT handles. The rest belongs in your project plan and budget:

Custom logic. V1 extensions built with the SAP Cloud Applications Studio (PDI, ABSL) do not run in V2. Logic is rebuilt with V2 key user tools (rules, validations, determinations) or as a side-by-side extension on SAP BAIP. This is usually the largest rebuild item.

Workflows and notifications. Rebuild them in V2. Many V1 scripts become configuration.

Integrations. Communication arrangements, ERP integration, marketing and third-party connections are set up again for V2. For the integration with S/4HANA, SAP provides standard integration content on the SAP Business Accelerator Hub. Our article on the Sales Cloud V2 and S/4HANA Public Cloud integration architecture shows how we set this up. Telephony is a separate topic, covered in our CTI integration guide.

UI adaptations and mashups. Rebuild them with V2’s adaptation tools and mashups.

Reports and dashboards. Rebuild them in V2 analytics or in SAP Analytics Cloud. It is a good moment to delete the reports nobody opens.

Email templates. Recreate them in V2; the placeholder syntax is different.

In our projects, the data transfer is the smaller share of the effort. Most of the work lies in the items above. For budget context, see our SAP Sales Cloud V2 pricing guide.

How long does the DTT workstream take?

These are the ranges we plan with for the data workstream alone. They are not SAP figures and they depend heavily on data quality and the number of extension fields.

Phase	Small (25 to 50 users)	Medium (100 to 200 users)	Large (500+ users)
Readiness check and V1 cleanup	1 to 2 weeks	2 to 4 weeks	4 to 6 weeks
V2 preparation and mapping	2 to 3 weeks	3 to 5 weeks	5 to 8 weeks
Transfer configuration	1 week	1 to 2 weeks	2 to 3 weeks
Test transfers	1 to 2 weeks	2 to 3 weeks	3 to 4 weeks
Production cutover	1 weekend	1 weekend	1 to 2 weekends
Validation	1 week	1 to 2 weeks	2 to 3 weeks
Total elapsed time	6 to 9 weeks	8 to 14 weeks	14 to 24 weeks

Phases overlap, which is why the totals are shorter than the sum. The overall V1-to-V2 project (rebuilding logic and integrations, training, go-live) runs in parallel and usually takes longer. For the bigger picture, see our V1 to V2 migration comparison or try the V1-to-V2 wizard.

Planning table for a medium-sized tenant

Week	Activity	Depends on	Result
1 to 2	Request DTT, run readiness check	V1 admin access	Readiness report and action list
2 to 4	Clean up V1	Action list	Cleaned V1 data
3 to 6	Prepare V2 tenant	V2 provisioned	Configured, empty V2
4 to 6	Extension fields and mapping	V2 configuration	Mapping document
5 to 7	Configure the transfer	Mapping document	Transfer ready
6 to 8	Test transfer 1	Transfer ready	Error list and fixes
8 to 9	Test transfer 2	Fixes applied	Validation report
10	Production cutover	Tests passed	Data in V2
10 to 12	Validation and delta	Cutover complete	Business sign-off

Add 20 percent to every estimate. Cleanup and mapping are the phases most likely to overrun, because nobody knows the real state of their V1 data until they look. Teams tend to underestimate this phase by about half, and it sets the pace for everything that follows.

FAQ

Where does the Data Transfer Tool run, and how do I get access?

DTT runs in your V1 tenant, in the Transition work center. SAP activates it on request: open a case on component LOD-LE-MIG-CNS with your V2 tenant details, then assign the Transition work center to the administrator role in V1.

Does DTT support delta migration?

Yes. Once an object has been transferred successfully, DTT switches that object to delta mode. Later runs pick up records created or changed in V1 since the initial load, which is what you need for the gap between the last test and the cutover. Test how your scenario handles records deleted in V1 and plan a cleanup pass after cutover.

Can I filter which records DTT transfers?

Not in the way most teams expect. DTT transfers an object’s data rather than a filtered subset, so data you do not want in V2 has to be cleaned up or archived in V1 before the transfer.

Does DTT work for Service Cloud V1 to V2 migration?

Yes. The transition tools cover Sales Cloud and Service Cloud, including tickets. Some service configuration, such as case types, has to be created manually in V2 first. The process is the same: readiness check, preparation, test transfers, cutover.

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

No. DTT is for V1 to V2 only. From Salesforce, Dynamics 365 or other systems, you load data through the V2 Data Workbench (CSV or Excel import) or the V2 APIs, for larger volumes usually via SAP Integration Suite. For spreadsheet-based sales teams, our guide to moving from Excel to Sales Cloud V2 covers the simpler path.

How do I handle custom objects with complex relationships?

Custom fields on standard objects move with DTT once they are mapped, and PDI field data is supported. Custom business objects with their own logic, relationships and UIs are rebuilt in V2 or on SAP BAIP. Their data is exported from V1 through the OData API and loaded into V2 through its APIs. That is project work, not DTT work.

What happens to my V1 system after migration?

DTT reads from V1 and does not change the source data. V1 keeps running until you decommission it. Agree how long users and auditors need read access, and plan the end of the V1 subscription as a separate step.

Is there a maximum data volume for DTT?

We are not aware of a published hard limit. Volume determines runtime, so use the readiness check to see record and attachment volumes per object, test with production volumes and plan the cutover window from the measured runtimes.

---

A V1-to-V2 migration is a project with a data workstream, not a data transfer with a few side tasks. DTT makes the data part manageable. The rest comes down to preparation: clean data, complete mappings, real test runs and a plan that tells the truth about the rebuild work.

If you are planning a DTT migration and want a second opinion on your readiness report, get in touch. We are happy to go through it with you.