Create index on 106 million row table
I'm leaving this as an answer, even though it's mostly an Extended Comment®.

You don't mention the index definitions, or the types of columns you're trying to index. You say the table is 200 columns, but unless you're creating a clustered index, that shouldn't matter. Unless you're trying to create a nonclustered index on 200 columns. If so, please reconsider.

Given that you're doing this across many different versions, it's likely that they're all on different hardware as well. In the case of creating indexes, hardware and existing indexes will have a dramatic impact on how long it takes to complete. It's not like you can tune the query behind index creation. Likewise, the ability for Enterprise Edition to parallelize index creation can be an important factor. 

Aside from hardware, system concurrency can play a part as well, either via blocking or overall resource usage. You don't mention if these are issues, so again it's a blind spot for anyone trying to answer.

In newer versions of SQL Server, you can choose to sort index creation in tempdb. This can help, as long as tempdb isn't Full Metal Potato© across your different environments.

Finally, you don't mention the recovery model of your databases. Since CREATE INDEX can be minimally logged, it may be worth switching to SIMPLE or BULK LOGGED recovery model if possible. This will depend on your RPO and RTO goals, and if they can be dismissed for a window to create the indexes.

A quick comment on step 2 that relates a bit to the comment above: If you create a table with no indexes, then do your data load and create indexes, it will likely be faster. Especially in SIMPLE or BULK LOGGED, you can use the TABLOCK hint to potentially get minimal logging on the insert as well as the index creation.

Your question will probably be closed as too broad, but I hope you find this Extended Comment® helpful.