Indexing columns for an UPDATE

I have the following data (names changed to protect the innocent and/or guilty).

create table Orders
(
    OrderID int identity(1,1),
    CustomerTIN int
)
create table OrdersStaging
(
    OrderID int,
    CustomerTIN int
)
create table InternalCustomerLookup
(
    InternalCustomerLookupID int identity(1,1),
    CustomerTIN int
)

I need to send the orders to an external vendor.  The vendor needs some kind of ID to identify a unique customer but they don't care what the actual TIN is.  Also, I don't want to send the CustomerTIN because it's sensitive info.  Instead, I'd like to insert records into a staging table that I can dump to a text file.  Here's the process:

POINT A

1. Load all orders into OrdersStaging and InternalCustomerLookup with all of the same data as Orders (basically a copy of the table)

POINT B

2. Insert unique CustomerTIN values into InternalCustomerLookup so I can keep track of the CustomerTIN.

POINT C

3. Update the OrdersStaging.CustomerTIN with the associated InternalCustomerLookupID.

POINT D

The actual tables I'm referring to have tens, sometimes hundreds of millions of records, and there are many more fields in the Orders and OrdersStaging tables.  #3 above took over 3 days when I had some clustered indexes that definitely shouldn't have been there for such a large update.  I can add/remove indexes as needed.

My question is... which fields should be indexed at what points?  I want to be able to quickly look up values for update, but I don't want inserts/updates to take longer when they have to recreate/reorder/rebuild.  Can someone suggest what indexes to have/not have at points A, B, C, and D?

Thanks!

Also, there are a few fields like CustomerTIN that also cannot be sent to the vendor and have their own lookup tables.  The situation is similar, but this OrdersStaging table will have to be updated 3 or 4 times in a similar manner.