How do I handle importing high amounts of transaction data into application DB?
We have a good sized Enterprise system that has many of SSIS packages taking data in and out of the system daily.

Some of the strategies we have used are:

Only process deltas especially in large files. To figure which records are deltas we use change tracking and send that data to tables in a separate database, so the process of figuring out the deltas when we receive a full file is pushed off onto a staging server. Only records that are new or changed go to the real production server.  On our busiest server, we have moved all teh processing except the final load off to a completely separate server. 

If the file goes directly to table that does not also have transactional data changes or multiple data sources, we might have two tables (and A and B version) and a view that selects from the active table. So we do our processing on the inactive version (possibly including dropping and recreating indexes), switch the table in the view (meaning there is about 1 second of down time fromteh user perspective), then update the new inactive table.

SSIS packages can be designed to run very quickly or not so quickly. So we may spend a lot of time performance tuning one that takes too long and affects production. 

Run the packages during the time period when there is the least usage on the server.