Migration With Penguins

In the last few days, Michael and I have been given access to a small area of the current University Portal to work with,originally we used it to test Microsoft InfoPath (see previous InfoPath post), however, after that failed I decided to use the area to test migration for a second time. I was confident that this time it would work as our site was much smaller than the one we tried previously. We used MetaVis again to carry out the migration and did it pretty much the same way we did the previous migration.

To test migration I first populated our page with test data and nonsense, adding a few lists, document libraries and images, this would help me tell whether or not the migration was successful.

We connected to https://portal.lincoln.ac.uk/C10/C6/PortalDelevopment and  http://adp.sharepoint.com/TeamSite/office365dev/migration/, again I found that it did not have to input my username and password to connect to our portal site. I then simply simply dragged the Lincoln portal site to the 365 portal site and the migration began. I was surprised to find that the migration process still took up to about 10 minutes, which I thought was odd considering there was very little on the page.

The migration completed successfully, with only a few minor errors, which consisted of these:

Copy group “Guest” – The server sent HTTP status code 401: Unauthorized

Copy group “Reader” – The server sent HTTP status code 401: Unauthorized

Copy group “Contributor” – The server sent HTTP status code 401: Unauthorized

Copy group “Web Designer” – The server sent HTTP status code 401: Unauthorized

Copy group “Administrator” – The server sent HTTP status code 401: Unauthorized

Copy group “anon” – The server sent HTTP status code 401: Unauthorized

Copy group “Content Manager” – The server sent HTTP status code 401: Unauthorized

Copy group “Member” – The server sent HTTP status code 401: Unauthorized

Copy group “ReadOnly” – The server sent HTTP status code 401: Unauthorized

Copy group “Role Analysis Group” – The server sent HTTP status code 401: Unauthorized

However, this was unimportant for this migration and was not needed, I also believe that this could easily be fixed when both portals are set up for migration.

Once it had completed I went to both portal pages to compare them. From what I saw, the migration was mostly successful.

 

Penguins

As you can see, everything was transferred correctly, the only two problems were the navigation (although I am not sure if this is because it isn’t the entire portal that has been transferred) and the layout of the page. I believe that this has happened because office 365 has multiple layout styles, where as SharePoint 2003 only has a few. This is easily fixed by dragging the ‘Content Editor’ web part over the the left of the screen.

penguins 2

So we finally have a successful migration using MetaVis, I will continue to test other migration methods and software and to research the migration of other areas including emails and users. for now it is just nice to directly compare Sharepoint Portal Server 2003 to SharePoint online, it’s clear which looks better.

RE

Migrating Outlook

So far we have only really looked at migrating our SharePoint server to the cloud, we haven’t really looked at migrating the Exchange server at all. I have come across an article on ZDNET describing their Exchange migrating experience, this article highlights a big issue with the migration process and the limitations of Office 365.

In ZDNET’s artcile, “Outlook: Cloudy (with a chance of email)” they describe their migration into the cloud as being pretty smooth, that is up until they got to the much larger mailboxes. We already know that Office 365 does not allow users to send attachments over 25mb but what I didn’t realise is that when migrating the exchange server, office wont migrate emails that already have attachments over 25mb. This limitation can halt the migration process, which of course can cause a problem for anyone migrating to the cloud. The smaller mailboxes will continue to upload, but any mailboxes left out of migration will be considered a failure.

ZDNET also came up with a method to avoid these problems

“Possibly the easiest way to deal with the large message problem is to use Outlook’s Search Folders to build a dynamic query that will find all messages over a set size. You can sort the resulting virtual folder by size, and remove all the messages (or attachments) that are blocking the migration.”

Once these changes had been made, the migration process was simply restarted and completed. Fortunately, the good thing about migrating the exchange server is that users will still be able to use their emails while the migration is in process, so there is no interruption to service.

For the university however, this could be a very lengthy process as there are an extremely large amount of mailboxes to migrate, with thousands of staff accounts and thousands of student accounts to migrate over to the cloud.

RE

Migrating in the opposite direction

After reading some blog posts we were concerned about some of the questions these bloggers had asked and never got an answer to. One of this questions was “what happens if you want to leave Office 365 for something else?”, this could be problematic as we wouldn’t want to loose all our data if we wanted to migrate back to SharePoint 2010 (When we do upgraded I don’t think we would go back to SharePoint 2003 ever again). After asking the question in the community forum I quickly got an answer. It is possible to migrate back to SharePoint 2010 but only through a migration tool such as MetaVis, Quest or AvePoint.

I’m still not sure why Microsoft are getting people to rely on 3rd party migration tools so much, even they rely on them for migrating their own systems. You would have thought they create their own migration tools, at the very least they could have made some more money from it.

RE

Microsoft Use Third Party Tool To Help Their Own Migration

In an article published by SharePoint Pro Mag, Microsoft themselves have used a third party tool to assist them with an upgrade from SharePoint 2007 to 2010.

“Just this week, it was announced that Microsoft itself, the Microsoft Technology Centers, migrated from dedicated SharePoint 2007 to SharePoint 2010 on an internal cloud hosted by MSIT (Microsoft IT), and even the MTC’s turned to a third party migration tool (by AvePoint) to migrate content to the cloud while maintaining metadata and configuration.”

I am very surprised that Microsoft has turned to a third party tool to complete their migration. I’m not sure if it’s just me, but it does not give their customers much confidence in what they (Microsoft) do, if they have to turn to another company for help regarding one of their own products. This potentially shows that using a third party tool to help with a companies migration should not be considered as shameful or cheating or using the ‘easy’ option.

The full article can be found at: SharePoint Pro Mag.

Microsoft Premier Deployment for Office 365

Microsoft Premier Deployment helps customers to make a safe and efficient transition to the cloud environment. Microsoft offer this service to Enterprise customers who plan to migrate 2,400 or more users. Microsoft offer two services, to either assist with the planning of the migration and then hand over to the organisation to implement the plan for the migration, or customers can opt to work directly with Microsoft’s deployment teams.

Microsoft will identify any issues with the computing environment that may need to be resolved to meet the requirements of Office 365 and provide a proposal to address any other gaps. To date Microsoft Premier Deployment has migrated over 2 million seats of fortune 100 customers to online services, using the standard tools their team uses.

Microsoft will also mitigate any migration and deployment risks with the help of an experienced deployment team, they will also manage your deployment budget by using a fixed price approach.