Migrate Single Site to Multi Site Instance

Hi all,

Sitefinity 7.0 will enable the easy migration of numerous single sites to one target multisite instance. The updated wireframes for this feature are here: http://encmod.axshare.com/

To illustrate with an use case:

1. User has 3 Sitefinity single source sites: “site a”, “site b”, and “site c”. He wants to unite them under one target multisite installation to make use of shared content b/n sites, decreased db size, and reduced effort for support and maintenance.
2. User creates a Multisite installation (Target), in it he creates multiple sites: “site 1”, “site 2”, and “site 3”. (User makes sure that all single sites, and the multisite run on the same Sitefinity version.)
3. User logs in to a single “site a”. In Backend he sees a section where he can setup the connection to the target server.
4. When he clicks on Done, he is taken to a screen where he can select:
   1. The exact site on the Target server to which to migrate data, in this case: “site 1”
   2. The data which he wants to migrate (options for granular selection are presented)
5. Once the selection is done, a click on “Migrate Now” starts the migration process.

   The data transferred during migration is the same as the one supported by Site Sync (for detailed list, see here). We will also add options for migrating: Users, Roles, and Permissions.

   The following data will not be transferred during migration:

   • Content items with Status other than Published (Draft, Scheduled for publishing, Awaiting Approval, etc.)
   • Version history of content items
   • Forums (Threads, Posts), Comments
   • System data: Configuration, File system, non-DB content - labels, themes, master pages, etc., Backend pages, Feeds / Search indexes, Workflow definitions, Personalization settings, and Responsive design settings
6. Once migrated, the data will be shared on the selected target site only.

So, in the case above: Page template “Template 1” from “site a” will be migrated as “Template 1” on “site 1”. On the Target instance, “Template 1” will be shared on “site 1” only (and not on “site 2” and “site 3”).

The procedure above can be repeated for migrating: “site b” to “site 2”, and “site c” to “site 3”.

Please review, and let us know if you have any comments on the behavior above. Do you have scenarios which we don't cover?

Hi all,
We’ll need your input on migrating Users, Roles, and Permissions.

As mentioned earlier, migration of sites will include the option to migrate users, roles, and permissions.  As you known, in multisite installations Users are Roles are shared across all sites, and there is no option to restrict them per site only. That complicates the migration since what was before a user on a single source site, will become a user across all sites on the target server.  

Here how we plan to achieve that:

On Migrating Users

There are two strategies for migrating users: Migrate Users to Different Membership Providers, or Merge Users to the Same Membership Provider.  In more detail:
 
Strategy 1: Migrate Users to Different Membership Providers on the Target Server

In this scenario, when migration starts from “site a” to “site 1”, a new user membership provider will be created on “site 1” with name “SiteA_Users”. All users from “site a” will be migrated to the multisite instance membership provider “SiteA_Users”.  

Similarly, when “site b” is migrated to “site 2”, all users of “site b” will be transferred to a newly created “SiteB_Users” membership provider.

The advantage of this approach is that all users who logged in previously on the single sites will be able to log in on the target multisite. The disadvantage is that they will have to select a membership provider upon login. Administrators managing users on the target site, will see them under different providers:  “SiteA_Users”, “SiteB_Users”, etc.

Strategy 2: Merge Users to the Same Membership Provider on the Target Server
In this scenario, when migration starts from “site a” to “site 1”, all users from “site a”>Default Membership Provider will be migrated to the Target Site> Default Membership Provider.

Similarly, when “site b” is migrated to “site 2”, all users from “site b” >Default Membership Provider will be transferred to Target Site> Default Membership Provider.

The advantage of this approach is that on the target instance all users will be in the same membership provider.

The disadvantage is that we will not be able to migrate duplicate users,.i.e. users with the same username or email. Such users will have to be transferred manually.
To illustrate:  user with username “a” and email “a@a.com” exists on “site a”.  When “site a” is migrated to “site 1”, so will be user “a”. Now, imagine that there is a user with username “b” and email “a@a.com”   on “site b”. When “site b” is migrated to “site 2”, an attempt to migrate user “b” will detect that user “a” with the same email (“a@a.com”) already exists on the Target instance. Therefore, user “b” will not be migrated and this will be reflected in the migration log. This user will have to be migrated manually with different email address. The problem is that If you have many overlapping users (with the same username or email), they will not be migrated and this will result in loss of important user information on the target site.

Another disadvantage of this approach is that passwords will have to be regenerated for all migrated users on the Target Server.

 As of now, strategy 1 seems more appropriate as it covers broader set of scenarios. If you had to choose one strategy, what would you opt for? What are your cases when migrating Users? 

On Migrating Roles
Similar to users, there are two strategies for migrating roles: Merge to Existing Roles or Migrate to New Role. In more detail:

Strategy 1: Merge to Existing Roles on the Target Server
In the case above, let’s say that there is role “Designer” on both “site a” and “site 1”, and you set the migration so that all role “Designer” from “site a” is migrated to role "Designer” on "site1”.

In this case, “user X” who is a “Designer” on “site a” will be migrated in role “Designer” on “site 1”. But since users are shared across all sites in the Multisite instance, that means “User X” will be a “Designer” on “site2” and “site3” as well.

Thus, when the migration is over, “user X” will have greater access privileges than he had before, as he will be a "Designer" on all three sites.

Strategy 2: Migrate to New Roles on the Target Server
To overcome the shortcoming of Option 1, you can choose to migrate to a new (and not existing) role on the target instance.

Let’s say, there is a user role “Designer” on “site a”. You can set this role to migrate to a new role “Designer_SiteA” on “site 1”.

In this case, “user X” who is a “Designer” on “site a” will be migrated in role “Designer_SiteA” on “site 1” (and therefore shared to:“site2”, and “site3). Also, the permissions from “site a”, which were linked to “Designer”, will be migrated to “site 1” as linking to “Designer_SiteA”.Since "site2" and "site3" do not have permissions related to the newly created role “Designer_SiteA”, "user X" will not have permissions for those sites after migration.

Now, imagine that “user X” is “Designer” on “site b”, and “site b” is migrated to “site 2”. Now “user X” will be both a “Designer_SiteA” and “Designer_SiteB” across all: “site1”, “site2”, and “site3”.

The outcome will be that “user X” will have the same privileges as before the migration, but this will be achieved by introducing new roles for each migrated site, which can be hard to manage over time on the target server.

To overcome this, In the future we can offer you options to merge different roles in to one.

As of now, Strategy 2 seems more universal in that it preserves the current behavior. If you had to choose one strategy, what would you choose? What are your cases when migrating roles?

Let us know if you have questions on the presented scenarios.
We look forward to receiving your comments and feedback.

 Kali
Sitefinity Team

I am really looking forward to this feature being implemented as I have 12 sites that need to be migrated this way.  Wouldn't it be better to login to the multi-site solution and the migrate FROM already existing instances?  In my case, my production environment isn't able to see my test environment but test is able to see production.  I like this approach so I can create a new site in the multi-site solution as I migrate the data from the site.