The real use case for table partitioning is fast load and unload of data.
If your warehouse tables and staging tables are in the same database, and have the same schema, you will be able to swap a partition from staging to warehouse very quickly. Similarly, when data has reached its retention expiry date and must be purged, it is very quick to delete a whole partition of data. This page and its ilk will give some pointers.
As each partition can be directed to a different filegroup your backup & recovery cycles could be shortened at the cost of increased complexity. For example, load one company's data, process it, then take a backup of the file(s) that hold that company. Perhaps several companies could be processed in parallel, knowing that file contention will be reduced through partitioning?
Indexes can be partitioned as well as the tables. Index maintenance can be performed one partition at a time. This could reduce contention and overall load on your system.
Using partitions solely for performance enhancement can be problematic. Every query will have to have the partition key in the predicate, as a minimum. Sometimes the optimiser chooses not to perform partition elimination even then.
Partitioning is no free lunch. It has costs as well as benefits. You must consider both sides and test well. As so often in DB design "it depends."
Short answer: yes it can help, because it's theoretically instantaneous. You would insert your data into a staging table with the same definition as your main partitioned table, and then switch it into the partitioned table, which is a metadata operation (schema lock).
Long answer: it might make performance suffer over the long run to have such a large table, and unless you move to later versions of SQL Server, statistics updates are quite difficult to manage.
If this is a read-heavy table, I'd consider using view partitioning instead. Each month (for example) would get its own table, with check constraints on a date column to help the query optimizer know where the data is physically stored, and a view over the top of that:
SELECT col1, col2, col3, col4 FROM period201501
UNION ALL
SELECT col1, col2, col3, col4 FROM period201502
...
SELECT col1, col2, col3, col4 FROM period201608
(or whatever). Then your metadata operation is the update of the view, as opposed to the switching in of the partitioned table.
Best Answer
Use ALTER TABLE SWITCH to switch the data of the table to a range-partitioned table that has only one partition for all the existing data, but for which new inserts will land in new partitions. Eg all row up to today land in one big partition, but new rows will fall into monthly partitions in the future.
Then perhaps later you have some time to split the big partition. If you use a RANGE RIGHT partition scheme, then you can split small partitions off of the RIGHT side of the large partition. If you use RANGE LEFT you can split small partitions off of the LEFT side.
Or, after you have switched to the new table you can INSERT the data from the old single partition into a new properly-partitioned staging table. Once that insert is done you can truncate the large partition, split the now-empty partition to match the staging table, and then switch the staging table in. Since the data in the old partition is read-only, you can perform the insert over time. Then the truncate, split, and switch-in are all metadata operations.