Effectively step 3 is redundant why delete the rows in the source, and then reinsert them, you're doubling the work load. Its should just be a case of

1) Import data

2) Update Changed Data

3) Insert New Data.

I agree with Eirikur, It sounds like a good candidate for MERGE.

I would also suggest that the key on both the destination table is clustered it should make the process significantly faster. so something like.

MERGE

(

Select *

, HASHBYTES('MD5',col1+'|'+col2+'|'+CONVERT(VARCHAR(100),col3)+.....) CheckSum

FROM table_a

) Dest

USING

(

Select *

, HASHBYTES('MD5',col1+'|'+col2+'|'+CONVERT(VARCHAR(100),col3)+.....) CheckSum

FROM table_b

) Source

ON Source.Key=Dest.Key A

WHEN MATCHED AND Source.CheckSum<>Dest.CheckSum THEN

UPDATE SET

Dest.col1=Source.col1

,Dest.col2=Source.col

,Dest.col3=Source.col2

--:::::::::::::::::

,Dest.CheckSum=Source.CheckSum

WHEN NOT MATCHED BY TARGET THEN

INSERT (Key, col1,col2,col3,.........,Checksum)

VALUES (Source.Key,Source.col1,Source.col3,.......,Source.CheckSum);

----

@pietlinden, there will be no benefits of partitioning and then using Switch, as you cannot guarantee that the data being altered will all be in the same partition frame, and 10 million rows really doesn't justify the additional overhead of partitioning.