You will require testing for Option 3 first in your dev enviornment, It will be ideal if you can bring Live DB to Development and do your testing before going for this option.

You can introduce a Migration step also, Where a new page type can be created and Update the page as require in this step. On Site run, you can change Start page.

Regards
/K

For step 3 it might be a good idea to have all "old" properties on the new page type, and when you see that everything is fine you could remove them. That way it shouldn't be a problem with losing data. 

In support of Option 3
Export Required Page
Import That Page on same site or in some other enviornment
Convert Imported Page

Regards
/K

Let's break it down.

Option 1 (create new startpage, copy existing tree under it, point to new startpage in config).
Your first issue is that your new startpage (assuming you gave it the same name as the original) now has an undesirable URL segment, e.g. /startpage1. 
You need to fix this, otherwise it will result in a new URL for all your subpages, and you'll get 404 errors for all inbound links (not to mention losing your link juice).
To fix this, change the URL segment of your original startpage (e.g. to /oldstartpage) so that you can use the /startpage URL segment for your new startpage. 
After that, go into Admin > Config and point to your new startpage.
Lastly (after testing the new startpage), delete the duplicate (old) page tree, including the old startpage.

You would be able to perform Option1 while the site is live, but there will be a short window where all pages effectively have a different URL than before. 
Also, depending on the number of pages in your tree and the complexity of your content types, the copy job might time out or quit unexpectedly.

Option 2 (create new startpage, move existing tree under it, point to new startpage in config).
Same problem as above, you need to fix the URL segment of the new startpage.
Then point to your new startpage in config, and delete the old startpage.
At least here you don't have a duplicate page tree to delete.

This approach can be performed while the site is live, but again, all pages will temporarily have a different URL. 
Also, as above, you run the risk of having the move job time out or quit unexpectedly. This might cause a nasty cleanup job. 

Option 3 (convert existing startpage to new type)
With this approach, you have no duplicate pages, no copy/move job, and no URL segment worries.
Before converting, you should make a copy of your original startpage outside the page tree. If the conversion goes wrong, you could just reinstate that one (be sure to fix the URL segment).
I'd also follow Erik's suggestion above - map all the properties you're going to reuse, but make sure the new pagetype also includes the obsolete ones. 
Also make sure you don't check the "Convert the selected page and all subpages" box.

Personally I'm in agreement that Option 3 is the easiest. 
Whichever you choose, I'd recommend testing it in your staging environment first rather than hotfixing a live site :-)