Lesson 2 of 5
Connecting source and target
10 min
Direct transfer depends on a working, secure connection between the SAP S/4HANA target and the SAP source, and on extraction software in the source. This is Basis and security work, but the migration team must understand it well enough to plan it, test it and recognize its failures.
The building blocks
| Component | Where | Purpose | Who sets it up |
|---|---|---|---|
| DMIS add-on | Source SAP ERP system | Provides the extraction functions the cockpit calls; the required version and support package are named in SAP's notes for direct transfer | Basis |
| RFC destination | Target SAP S/4HANA system | Defines how the target reaches the source system: host, client, logon user, security settings | Basis |
| RFC user in the source | Source SAP ERP system | Technical user the cockpit uses to read data, with the roles SAP's documentation specifies for direct transfer | Security |
| Migration project | Target SAP S/4HANA system | Created with the direct transfer approach and the RFC destination to the source | Migration specialist |
| Communication arrangement | SAP S/4HANA Cloud Public Edition only | Sets up the RFC connection in the cloud | Implementation team |
Components of a direct transfer setup.
Use the SAP Notes as the checklist
SAP maintains central notes for direct transfer that list the required DMIS version and corrections for each target release, and frequently asked questions about the step sequence. Community material quotes different minimum DMIS support packages depending on when it was written, which is exactly why the current notes, not a blog, must drive the setup. Contoso's Basis lead checks the notes for the target release at the start of each mock and applies new corrections in the source and target before the run.
Security considerations
- The RFC user is a technical read user with access to large amounts of business data. Restrict it to the roles SAP specifies and lock it outside migration windows.
- Use secure network communication on the RFC connection where your security standards require it, because business data, including bank details and addresses, flows over it.
- Log who created and ran migration projects in the target; the cockpit's run history and messages are part of the evidence.
- Decide who may change the RFC destination; pointing a project at the wrong source is an easy and serious mistake.
- Mock -6 weeksNotes and add-onCheck SAP's notes for the target release; plan the DMIS installation or update in the source
- Mock -4 weeksUsers and destinationsCreate the RFC user and roles; create and test the RFC destination
- Mock -2 weeksConnection testCreate a small test project; select a few records for one company code
- Mock -1 weekCorrectionsApply any new notes; confirm firewall and job capacity
- MockRunFull selection and load; issues logged against connectivity or data
What would you do?
On the first day of Mock 2, the selection for every object fails immediately with a connection error. Yesterday's test project worked. What is the most likely first check?
A practical point: when the source copy is refreshed from production, its logical system name, client and users can change. Put "re-verify RFC destination and RFC user" into the run book after every source refresh, so the first mock day is not spent rediscovering it.
- Direct transfer needs the DMIS add-on in the source, an RFC destination in the target and a technical RFC user in the source.
- Public Edition uses a communication arrangement for the RFC connection.
- SAP's current notes define the required versions and corrections; do not rely on old blogs.
- Secure the RFC user and connection, and re-verify them after every source refresh.
Check your understanding · not graded
Lesson check
1. Which add-on must be installed in the SAP ERP source for direct transfer?
2. Where is the RFC destination to the source defined?
3. What should drive the required DMIS version and corrections?
4. After a source system refresh, what should be re-verified?