The most likely scenario moving towards the ideal future setup is scenario 2. The least overhead option is to leave the sites as they are.

URLS

Moving the content of any faculty site will need to take into account the desired url of the new location. Currently each faculty or school site sits on a URL applied to the site asset, i.e:

www.victoria.ac.nz/engineering

If the new location structure is to maintain a similar URL and not be nested deeper in the site, the current site's URL will need to change to accommodate the URL being used by assets in the new asset tree location. This can be managed using server side rewrites proxy configuration or potentially by Varnish temporarily.

If the location is deeper, there is no conflict. The URL can be removed from the sub site and applied as a short URL remap to the new parent asset once the new location is ready.

Migration Method

Because of the nature of the structure and implementation, in consultation with Matt Dalziel (Squiz Sys Admin) we wouldn't recommend a scripted or automated way of moving (or new linking) the content to its new location.

The most reliable, robust and predictable way is using the standard means of moving content via the asset tree. Literally, highlight all assets and drag to new location. This will mean that it will have to be undertaken for each site, but in our opinion is the lowest overhead, least risky means to achieve moving the content.

Implementation

After talking to Vaughan Curd (Squiz Developer) and reviewing initial migration of faculty and schools sites documentation, it appears on a whole the implementation is fairly standardised between sites. The sites share global design resources and nested assets and it will need to be assessed if they will continue working post move or need to be addressed. There are metadata fields applied to the site assets that appear to facilitate some functionality.

There are some custom pages, such as site specific 404 pages, that will carry over with the migration and potentially need to be tidied up if no longer relevant. There may also be implementation per site that may have occurred in between deployment and now that is difficult to account for and may break on move.

The HTML appears to be in a ideal a condition as possible to apply a new design template.

However, things like Metadata Schemas, Workflow & Permissions are all applied to the site assets and if are to be carried over, will need to be reapplied to a parent node in the new location.

Post Migration

It is unlikely that the sites will be able to be dropped into their new location and everything work perfectly. It is likely that there will need to be some tidy up per site. To this end it will likely be better to new link the content and keep it accessible at its old location until ready to cut over.

The content will still be live while remedial work is undertaken unless decided the content is made unavailable while working on it. A content freeze may also be necessary.

Browser not supported