Best Way To Migrate Existing Production Database To New Physical Storage Structure
I am not a SQL Server DBA, I use MySQL for my jobs. But some truths are universal. :-)


  1) Should I expect any gains in performance or reliability breaking up the main data file in the manner I described?


I have observed that the benefit of any scalability optimization depends on the queries you run. 

It's practically the definition of optimization that any method of optimization will improve one type of query workload as it worsens some other types of workloads.


  2) How do I make these changes on a production database server where I can schedule (at most) a 30 minute downtime window per day?


I would set up a replica server (I gather in SQL Server land these are called Subscribers). Restructure the physical tablespaces of the replica. Then it doesn't matter how long it takes, as long as it can catch up to the master after the restructure is done.

I'm assuming SQL Server replication is asynchronous and also agnostic about physical layout, as MySQL replication is. But I don't know that SQL Server supports this.

Once you're done restructuring the replica, and it catches up to be in sync with its master, you can "cut over" probably by changing DNS entries for the respective server instances. Then the downtime is minimal, and brief, regardless of the size of the databases. The downtime should include a few moments to make sure all changes from the master have "drained" and been applied fully to the replica.

The tradeoff being that you need an extra set of DB server(s), at least temporarily. This is a case where using virtual servers or cloud servers can really save you!