I'm looking for some advice on the following situation:
We have a website that is divided into a global section (global start page, investor relations etc) and then regional sites (country landing pages) as children of the global start page. In the solution we have 2 sets of page templates and views. The first is a legacy set that the global section and some regions still use and then a new set with a different design that some of the regions have been migrated to (re-implemented).
It is now time to migrate the global section (including the site start page) onto the new templates and I am wondering how best to do this in terms of the go live execution. I see the following options:
Currently option 3 is the favourite but the Convert Page Type tool performs a non-reversable action and if something was to go wrong then we would either have to try and convert the page back to the old page type (some properties might be lost doing this) or rely on a doing a database restore which could take some time during which the site will be down.
Does anyone have any better suggestions?
Thanks in advance
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.
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 3Export Required PageImport That Page on same site or in some other enviornmentConvert Imported PageRegards/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 :-)