In SQL Server, you can create file groups that consist of 1 or more files. You can then migrate data into those file groups individually by rebuilding the clustered index for each table on that file group.
You can also do the same for indexes by rebuilding the index by specifying the desired file group. You can use file size caps to ensure the files do not grow larger than 512 GB.
You will want to do this prior to migrating to the new drive array so that you can do a backup/restore or a detach/attach to the new array with no issues. You will also want to shrink the
PRIMARY file group after you're finished migrating data to the new file group(s). (I'm assuming everything is in
This will be your easiest solution that will not require any coding changes but it will incur some significant performance hits while the data is being moved.
Your performance will likely go up markedly by splitting the data into multiple files and moving to SSDs. I would suggest doing a backup first, and don't do detach-attach if you need to physically move files around - backup/restore is FAR safer.
Multiple filegroups are superior to multiple
PRIMARY files as they allow piece-meal restores, which can help get the database up and running far more quickly in a DR event.