I have decided to look into Migrating from the universities current system, sharepoint 2003 into sharepoint online (office365). After browsing the Internet for a couple of minutes it appears that the MetaVis migration tool is quite popular, it supports migration from:
- SharePoint 2010, 2007, WSS 3.0, 2003, WSS 2.0
- Office 365, BPOS and hosted SharePoint
- Local or Network File Shares to SharePoint 2010 migration
- Microsoft Exchange Public Folders and Microsoft Outlook
- Windows Server 2008 R2 File Classification Infrastructure (FCI)
This appears to be quite a simple way of doing things however this is also a paid service. Microsoft also have documentation for planning, preparing and implementing the Migration process for enterprises. This document goes into detail even suggesting meetings and backup methods. I will attempt to summarise some of this document and post into this blog.
Microsoft recommends that we expedite our Office 365 deployment by proceeding in three distinct phases: Plan, Prepare, and Migrate. Organizing our deployment according to these phases provides our project team with high-level time frames that control the pace of the deployment while keeping individual tasks serialized. It is common for tasks outlined in the Plan phase and Prepare phase to occur simultaneously and for tasks in the Prepare phase and Migrate phase to overlap.
The planning consists of several stages, the most Important being
- The kickoff meeting
- Customer environment discovery
- Key planning considerations
- Long lead time items
- Client hardware and software requirements
- Sharepoint Online planning
I will summarise these next week
Now, my skills in JQuery are very minimal, never really used it much but I have just started picking bits up so I’ve decided to start using it where I can, so there is probably an easy way round this that I am unaware of.
In previous blogs we have described the difficulty in editing the public facing website outside of the sandbox tools,and not being able to locate let alone edit the root.master page. Since then we have discovered more permission settings that were only available to Tim, we now have majority access to the files containing the public facing site, including root.master. I thought this might be a nice time to add some JQuery in after opening the master page in advanced settings and inputting/referencing the JQuery library I clicked save, Sharepoint Designer asked me if I was sure as this would change it from the site definition (I was aware of this, after all, I did just add some extra code in). Before adding any actual JQuery into the site pages I decided to check the site in the browser, it didn’t load, for some reason it wont accept any variation of the root.master page, it has to be to the site definition so I was forced to reset the root master page. Now I could create an entirely new master page mimicking the root master, but this would be time consuming and quite annoying.
There must be a better way to add Java into the site as recreating the root master doesn’t seem like the right way, it shouldn’t be so difficult, the only thing I am wondering is if it would be any easier for the Enterprise version of 365 as the P1 plan claims that no IT professionals are required, so obviously that leads to very little customization beyond the sandbox.
After spending some time fiddling with the Public face site, Michael and I have found that customizing the site beyond what Microsoft has provided is rather difficult and headache inducing.
I stick by what I said about editing the .ASPX files, it is very easy adding new content in HTML using Sharepoint Designer, however, it’s the master page that is proving to be the big problem. We wanted to edit the structure of the website, change the navigation and the shape of the site completely, this isn’t covered in Office 365 ‘Out-0f-the-box’ tools, so the sites master page needs to be edited. This is a problem, Microsoft does not allow you to edit the master page provided and leaves the user stuck with what they give you, the phrase “You’ll get nothing and like it!” springs to mind.
One user claims to have a workaround for this, copying and editing a masterpage outside of Sharepoint, reinserting it into the correct folder and editing the .ASPX files to accept the new master page. I’ll report back once I have tested this.
Microsoft Office 365 comes with an external customer facing website for the users. This is a prebuilt website using a prebuilt master page and CSS file. Office 365 gives the users the ability to easily update the website directly from the 365 Team Site, using the inbuilt tools provided. The user has the ability to add/remove pages, edit content and insert gadgets. Gadgets can be a useful tool to the developer, it allows certain useful objects to be inserted into the site without any programming knowledge at all, for example, the user can add an interactive map into their site, giving the consumer directions on how to reach their store, the user can also add a ‘contact us’ form into the site which will send an email direct to whoever deals with consumer questions. This is not the extent of the site customization.
We have found that many websites reviewing Office 365 have had an issue in the web development side of things, claiming that there are very few ways a user can customize their site. They say that a user is not able to edit the the HTML of the site, however, I have found this a fairly simple thing to accomplish. An external web .ASPX page can be taken from Microsoft Workspace 2010 and opened in Sharepoint designer. From here I have easily been able to add new content into the website in HTML form, for example, I inserted the Database that I created the previous day into the site using an iframe, this was fairly easy and it looked very appealing. Unfortunately, their issues with the web development area aren’t completely unfounded. When editing the external page, I realised I needed to alter the master page file, after sometime it became clear that it was hidden from the user. This meant that I was not able to edit the entire look of the page at all. Although there is a way to work around this, the user can create another master page from scratch and upload this onto the server and direct the site pages to this master page rather than its original master page.
This custimazation allows the developer create the customer facing site, making it look however they want and not just an extension of Sharepoint and Office 365.
Office 365 integration with the Office desktop apps appear to be quite useful and impressive, however, there are still some problems with it. One flaw we found was with the compatibility between web and desktop apps. I found my self rather annoyed that after creating a mock payrole Excel spreadsheet and uploading it to SharePoint Online, it could not be viewed on the 365 website, this was because the desktop appwas not fully compatible with the web app. There are certain features that the desktop app has which the web app cannot use, in the spreadsheet that I created I used validation fields in some cells, this feature was not supported int eh web app there for not accessible on 365. Granted the file can still be opened from the Cloud on the desktop app but the user might not always have Microsoft Excel installed on their machine. Although not fully explored this is true for other Office desktop features. I find this to be a huge flaw in Office 365 and I would hope that this is sorted out for the release version.