Just my opinion, but do you need ALL of the ERP data?
The reason I ask is if you aren't needing all 130 GB of data, it MAY be faster to use SSIS to just pull across the data you require. SSIS can handle data transformations as well, so it MAY be able to handle the entire process for you. My preferred approach is if the source table is required by more than 1 transformation, the source table is copied 1:1 from source to destination with a few extra columns added in (package name that copied the data over and the timestamp that the package ran. This is to make troubleshooting easier). If the table is used by ONLY 1 transformation, then keep it in memory and off disk (as disk is USUALLY the slowest operation in the chain).
Two problems that come with SSIS are licensing and memory. Licensing is an issue because you NEED a SQL Server license on the server that SSIS is installed on. What I mean is that if Server A is where you are hosting your main SQL instances and Server B is where your data warehouse is and that is all you have for servers with SQL licenses, SSIS needs to be installed on Server A or Server B (doesn't need to be on both) OR you need to purchase another SQL Server license to install SSIS on Server C.
With memory - SSIS operates OUTSIDE of SQL Server, so it needs its own memory. What I mean is if you have Server A configured to use 90% of the memory for SQL Server and you install SSIS on there, when you run an SSIS package, it will request memory outside of that 90% and MAY end up paging to disk which will make your SSIS package performance take a HUGE hit. So you need to make sure SSIS has enough memory to do its magic.
One other issue that CAN come from SSIS is package sprawl. What I mean is that a simple SSIS package becomes more and more complex as business logic increases and eventually you get to a point where the SSIS package "just works" and is a huge mess that nobody wants to touch. If you do go with SSIS, I encourage you to keep SSIS packages simple. If it starts to look complex or scary, look at what can be broken out into a second SSIS package. Keeping them simple also decreases support time. If an SSIS package has 10 steps and runs in 1 minute, testing it takes 1 minute. If the package has 1000 steps and runs in 1 hour, testing takes an hour. The more simple the package is and the faster it can run, the faster and easier it is to test and debug.
There are also a lot of tips and tricks related to SSIS that you can do. My 2 big ones are:
1 - avoid "SELECT *" like the plague as it will almost always bite you in the end.
2 - Data sources, where possible, use TSQL for the data pulls rather than from a table or view.