Not really. You have to rebuild the structures. This means data movement. The more data you have to move, the longer it will take.
One possibility would be to snapshot a moment in time, say with a backup. Migrate all that data into the new structure, with temporary table names. Then, after you get it done, migrate the changed/inserted/deleted data from the existing tables. When that's done, change the table names. That's probably your best bet. You won't be able to use log shipping or anything like that because you're restructuring the tables.
Of course, one question, WHY are you partitioning the data? Is it because you're having a hard time managing it and need a sliding window or similar behavior? Or, do you think partitioning will improve performance through partition elimination? If it's that second thing, stop. For most people, partition elimination is hard. They don't have the structures, or worse yet, the queries, that can support good partition elimination. If you find that your queries today are doing lots of scans, then your queries after you partition the data will be even worse. Unless you're going after partitioning because of data management, I really don't recommend it. It's a poor tool for performance enhancement.