First of all, you should have a solid reason for moving the table to new file-group most preferably on a different drive. Secondly, you should keep in mind that there could be downtime required. So you have to plan accordingly.

There are some solutions , but the best solution would depend upon your environment and data structures. If you have that table without any dependencies, without B/LOB data type etc. data, and you do not want to move such data, it will work great. Moreover, if you have ENTERPRISE edition, you could use index build ONLINE option to move the data without a downtime (some conditions do apply)

Keeping in mind the limitation of moving B/LOB columns etc., non-flexibility of the CREATE WITH DROP_EXISTING clustered index and table data could be huge, my preference is something like (Hope not missing something)

TAKE BACKUP OF THE DATABASE

MAKE SURE THE NEW FILE HAS SIZE AT LEAST EQUAL TO THE TABLE

GET ALL DEFINITIONS RELATED TO THE TABLE (WOULD BE USED FOR NEW TABLE)

CHANGE THE RECOVERY MODEL TO SIMPLE OR BULK_LOGGED

CREATE COPY (JUST MAIN STRUCTURE)OF THE TABLE ON THE NEW FILE GROUP

DROP FOREIGN KEYS IF ANY

DROP NON-CLUSTERED INDEXES / MANUAL STATISTICS (OFTEN OVERLOOKED)

CREATE CLUSTERED INDEXANF NOT ANY ON EXISTING TABLE (PREFERABLY IDENTITY COLUMN)

MOVE THE DATA IN BATCHES (SORTED IF POSSIBLE) TO KEEP THE LOG FILE IN CHECK IN CASE OF SPACE CONSTRAINTS

BACKUP LOG IF POSSIBLE

VALIDATE THE DATA IF POSSIBLE

CREATE CLUSTERED INDEX ON NEW TABLE (IF NOT POSSIBLE BEFORE)

CREATE NON-CLUSTERED INDEXES / MANUAL STATISTICS

VALIDATE REFERENTIAL INTEGRITY BY CREATING FOREIGN KEYS IF ANY