There is a standard pattern for this.
- Extract the data (from the CSV to your temp area)
- Transform the data (clean it, convert it, format it, join other stuff to it, make it compatible with your new system)
- Load the data (update/insert/delete to your live tables)
This is where the acronym for ETL comes from - http://en.wikipedia.org/wiki/Extract,_transform,_load
The primary advantages you have are that at point 1 you have only 1 thread/user loading the data so it can be extracted quickly, then at stage 2 you are manipulating the data without causing any locks on other tables. Finally, once the data is ready, you are able to load it in the quickest method possible to your live tables.
Your two biggest (often competing) concerns are Simplicity and Speed. Simplicity is great because it involves less code, makes for less debugging required and makes you far more confident that your data is clean. Sometimes you have to sacrifice simplicity for speed however.
In your case, since you are only loading a few million rows, I'd suggest you just reload the staging table every time so every single load uses the same ETL process. This keeps your ETL mechanism easy to code, maintain and explain.
FYI - if you're using SQL Server, check out SSIS.