Best Practices for Migrating to SharePoint Online in Office 365

Written by Jason Miller, Senior Consultant, Summit 7 Systems

To the cloud

Thanks to SharePoint 2013, SharePoint Online in Office 365 has been significantly improved. SharePoint Online, originally considered to be just a shared document repository, has now evolved into a true collaboration platform. Businesses can finally harness the power of Office 365 for enterprise-level applications.

In this paper, you’ll learn why Office 365 is better than previous versions and how to forklift your data there. We’ll discuss the out-of-the-box migration options as well as what to look for in a third-party tool. The migration undertaking is quite a significant project. You’ll need to treat it with care, so we’ll spend ample time analyzing the importance of pre-migration readiness. We’ll also take a look at whether you should consider moving your entire data set to Office 365 or keep some of it in your private data center.

Considering your optionsYou’ve probably already considered Office 365 in many discussions with your senior management. They’ve heard all about it and they want you to investigate it. That might even be why you’re reading this paper. Most of us know what a cloud service is by now. Why would you consider the cloud? Do you know what your Office 365 options are? Did you know you have options?

Making a case for the cloudRunning a data center is expensive. Let’s break down the costs of running a local server environment. You’ll be paying significant costs for:• Data centers

• Racks

• Power

• Network connectivity

• Physical security

2

• Network infrastructure

• Firewalls

• Load balancers

• Switches

• Backup infrastructure

• Servers

• Storage

• Server hardware

• Support agreements for the hardware

• Storage Area Networks for highly

available storage

• iSCSI or fibre-optic

• Storage hardware

• Software licenses

• Operating Systems

• Server software

• Client-Access licenses

• Support agreements

• Support staff

• IT support for servers

• IT support for clients

• IT support for network infrastructure

• IT support for storage infrastructure

• Security staff

When you move your solution to the cloud, there’s a high chance you’ll be able to get rid of most (if not all) of those costs. Sounds great, right? In this day and age of shrinking IT budgets, you need to stop and wonder if you truly need to stay on-premises.

There are at several major types of cloud infrastructure solutions. Each model has its own features and cost. The basic rule of thumb for cloud solutions is that the more complex the solution, the more features and control you’ll enjoy. The more features you implement, the more it will cost you. The complexity comes with a high degree of control. Therefore, more control means more complexity and cost. If you’re willing to give up control, you’ll save money. The right solution is the one that properly balances cost, complexity and control. Office 365 is considered a Software-as-a-Service (SaaS) solution.

There are a few other cloud models other than SaaS, like Infrastructure as a Service (IaaS) or Platform as a Service (PaaS). The IaaS solution is what most people think

of when they consider a cloud solution. With this type of solution, a provider usually offers virtualized servers for you to control. These virtual servers leverage all of the highly redundant network and storage made available by the vendor. A PaaS solution implements many types of web services or libraries for your use (a la Windows Azure).

Office 365’s benefitsOffice 365 offers a good balance of control and cost. Office 365 takes away the pain of managing Microsoft Exchange, Lync and SharePoint servers (unless you decide to implement a hybrid environment, of course). Microsoft supplies the servers and network infrastructure. Depending upon the type of licensing you choose, you can use the Office client software to hook up to their services or use the existing software.

Let’s take another look at the list of on-premises costs and strike through the costs you save by using Office 365.• Network infrastructure

• Firewalls

• Switches

• Connectivity to the Internet

• Support staff

• IT support for clients

• IT support for network infrastructure

That’s a significant chunk of change. You still have to maintain network connectivity for your office to the Internet, but you won’t be using those in a data center of any kind. That requires a little bit of local support staff. That staff can be combined with the staff supporting your clients if you have the need.

If you choose to go with a hybrid deployment, some of those costs will remain on your plate. Your requirements will dictate what you do with the cloud and what stays on-premises. A lot of these decisions will impact your information architecture as well. You may even decide that a hybrid implementation is a good idea because you’re not completely sold on the whole cloud thing.

Office 365 offers a good balance of control and cost. Office 365 takes away the pain of managing Microsoft Exchange, Lync and SharePoint servers (unless you decide to implement a hybrid environment, of course).

Share:

3

There is one “gotcha” with any cloud solution, however. To use the cloud, you must have a good, solid connection to the Internet at all times. It doesn’t matter what service-level agreement you have with your cloud solution vendor. Your Internet provider’s SLA must be equal or greater to that of the cloud vendor. If you do not have a connection to the Internet, you do not have access to your data. That’s usually no different than a data center, unless of course your data center is on site with your client desktops.

The evolution of Office 365Microsoft first launched Office 365 as the Business Productivity Suite Online, or BPOS for short. BPOS was Microsoft’s first response to the growing threat of cloud solutions that offered Office competition at a very cheap cost. BPOS was constructed from several solutions that most typical enterprises demanded:• Microsoft Exchange 2007

• Email and calendaring through

Microsoft Outlook and Outlook

Web Access

• Microsoft Office SharePoint Server

2007/2010

• Document collaboration and sharing

through a web browser

• Office Communications Server 2007/2010

• Instant messaging through the OCS

2007 and 2010 client to other users of

the enterprise

• Microsoft Office Live Meeting 2007

• Desktop sharing and whiteboards for

virtual meetings

Microsoft hosted the service and charged a flat per user monthly fee. They soon discovered, as many enterprises discovered on their own, that these versions of server software were challenging to use in a hosted cloud environment.

Office 365 was announced as the new name for BPOS in October 2010. After a private beta period, Office 365 was officially released to the public the following summer.

The service offerings haven’t changed much since then, but the versions of software driving the solution have been upgraded several times. Today Office 365 provides the Office 2013 (Office 2011 for Macs) level of service and solutions—with one exception; Microsoft Office LiveMeeting 2007 was removed and all meeting functionality was introduced in Lync. The client and servers, however, are still available for Office 365 customers in case they are required for legacy purposes.

All of the customers who used BPOS and Office 365 prior to the change benefitted from the upgrades. Every customer paid a flat fee but was upgraded automatically each time the service was rolled out. The amount of savings was enormous. Each customer did not have to spend the time, energy and money to upgrade the version of the server software they used. Microsoft released the upgrades and service patches into Office 365 automatically. This release cycle continues today. Microsoft has publicly stated the intention to release upgrades to the service quarterly. In addition to these quarterly patches, Microsoft provides security upgrades as soon as they are available.

This benefit is also passed along to the clients. Microsoft provides updates to the desktop and mobile clients when required. For Windows clients, this is even more powerful. Some versions of Office 365 provide streaming desktop clients that are fully patched without the need to perform a complete installation.

Microsoft has also done a lot of work to build an ecosystem around the “Microsoft account.” This Microsoft account ties in to the consumer-based versions of software (Hotmail, Xbox Live, etc.), as well as the professional Office 365 solution. You can tie your accounts into both services with a single logon or split them across multiple accounts to keep your work and home lives separate.

Share:

4

Office 365 can also work with single sign-on capabilities by synchronizing your Active Directory for authentication. At least one domain controller and a synchronization server on-site are required to make this work.

Today you can use the power and agility of Office 365 for your entire organization or consider a hybrid deployment. A hybrid deployment allows part of your data to be stored in Office 365 while the rest stays in your on-premises data center. This option should be considered if you have SLAs with users or security requirements that prevent the use of Office 365 with some data. Office 365 uses SharePoint 2013 to merge cloud data with on-premises data into a single user experience. Think about your SLAs and security requirements to decide whether you should dive into Office 365 completely or deploy a hybrid farm.

Slice and dice: how Office 365 is pricedMicrosoft has a habit of slicing up products into several different versions in an attempt to fit the product to the right need for the right cost. Office 365 is no different. Microsoft split the offering into several different classes of licenses1. Take a moment to consider what category of user you are and then decide from the license offerings to fit your requirements. You can also add a la carte options to beef up the service based on your needs. The model is a per user, per month fee for all of the options. Not every price level provides the same services, so be sure to do your homework. Some of the license levels even include client side licenses.

Here’s a look at the different categories of licenses. Decide which market segment means the most to you. Remember that a lot of this depends on the requirements for your project. You should at least be somewhat familiar with them before continuing.• Office 365 Home Premium: This option

targets consumers and families. It includes

access to most Office applications for

home/non-commercial use (excluding

InfoPath and Lync) on up to five devices.

20 GB of SkyDrive storage, 60 minutes of

Skype international calls per month are

also provided.

• Office 365 University: A discounted version

of Home Premium intended for students.

It is similar to Home Premium, except it is

purchased on a discounted four-year plan.

The client software may only be used on

two devices per user.

• Office 365 Small Business: Offers access

to hosted Exchange, SharePoint, and Lync

services only. If you choose this plan, you

must provide Office client software to your

users separately.

• Office 365 Small Business Premium: This

plan targets 1-10 business users in an

organization. It offers access to Office

applications on up to five devices per user.

The backend services are expanded: hosted

Exchange (with 25 GB mailbox), SharePoint

(with 10 GB of storage, plus an additional

500 MB per user), and Lync services

are provided.

• Office 365 Midsize Business: This plan is

recommended for businesses with 10-250

employees. This solution provides the

client software for users to install on up to

five devices and all of the backend services

to hook them up for collaboration in the

cloud (hosted Exchange, SharePoint, and

Lync services).

1http://office.microsoft.com/en-us/business/compare-office-365-for-business-plans-FX102918419.aspx

A hybrid deployment allows part of your data to be stored in Office 365 while the rest stays in your on-premises data center. This option should be considered if you have SLAs with users or security requirements that prevent the use of Office 365 with some data.

Share:

5

• Office 365 Enterprise: Intended for

use in enterprise environments. Offers

access to all Office applications, hosted

Exchange, SharePoint, and Lync services,

plus enterprise-specific legal compliance

features and support.

• Office 365 ProPlus: Office 365 ProPlus is a

new way to license the Office client desktop

suite. You may pay a per user/per month fee

to install the software on up to five devices

per user. This solution does not include

backend services in the cloud. It can be

used to augment one of the other options.

The a la carte options will show up after you’ve signed up for Office 365. You can add storage for SharePoint, archiving for Exchange or, in some cases, unified messaging if you have a compatible telecom provider. Anti-spam and anti-malware features for Exchange Online are also available at an additional cost. There are many options to choose from; check them out in the administrative dashboard by clicking “Purchase Services” once you’re signed up. All of these optional prices will be added to your monthly fee.

The decisionBefore you make a decision on the type of Office 365 deployment you need to analyze your requirements. Analyzing your requirements is the most crucial part of your migration project because these requirements will drive your decisions through the entire migration project. Now that you understand your options, it’s time to begin your migration project. What follows is your roadmap.

A migration project

You’ve decided to go. How do you get there? The best type of information technology project is one that is driven

by milestones. Almost every project framework follows this approach. You should consider milestones for your project and use each phase to drive toward that milestone alone. Milestones contribute to the overall success of your project and also give your executives a firm, friendly way to verify its success.

Let’s use this model to put together an example. We’ll use this to highlight best practices for the migration and pitfalls you should avoid.

Get started: identify stakeholders and map milestonesThe first thing you need to do is identify your stakeholders. Your stakeholders include a variety of people. Most of the time, you will have more than one stakeholder. The list of stakeholders may contain your boss, the CIO, the company owner, or even the board of investors. Keep in mind that the list touches all levels of employees. In most organizations there is no success without making the office workers happy. Who are the assistants to the leaders of the business? Consider the warehouse workers or the mailroom staff. They’re stakeholders too. If they aren’t happy, you’ll be sad.

Get to know all of these stakeholders. List them and understand their individual daily challenges with the current system. The happiness of your stakeholders will guarantee the success of your project.

Next, map out your milestones. The important thing is to decide the milestones and verify that your stakeholders are in agreement on them. It’s important to include the stakeholders in this process.

Analyzing your requirements is the most crucial part of your migration project because these requirements will drive your decisions through the entire migration project.

Share:

6

Above is a list of milestones to consider. Each one contains a list of suggested actions to validate the milestone.

As you can see, each milestone and activity logically moves the project forward. The milestones also ensure that users and stakeholders are kept in the loop of communications. An added bonus of this approach is the documentation being produced for the project. Each document is not only written and reviewed, but also signed off on by the stakeholders every step of the way. If there’s ever a problem with the system at the end of the project, the documentation can be reviewed to understand the history of the problem.

You may also notice that there are four planning phases in the project plan before you actually do anything substantial toward migration. This is intended. When you’re going through a project with your company’s most critical data (don’t argue with me about this one, I know your company’s critical data is in SharePoint), you want to be sure to spend as much time as possible planning and testing the migration.

One of the toughest aspects of this approach is patience. Many users or stakeholders may not understand the need to take it slow. Indeed, you may find yourself wanting to just “push the button” to move the project forward with little or no documentation and no buy-in from the users. Remember the conversations I’m sure you’ve had with many users, though. How many times have you heard the users complain about the current system? How many of them truly understand why it operates the way it is running today? Do you want to hear those same complaints about the new system after migration?

I didn’t think so.

Requirement collection phaseThis first phase of your project is easily the most important. The information you collect in this phase will drive the documentation, direction, focus and happiness of your overall project.

Much of this is covered in an earlier white paper, Best Practices for Migrating to SharePoint 2013. The requirement collection steps covered in that white

Phase Action Milestone

Requirements collection Interview users, administrators, executives of the system. Collect requirements from each. Take inventory of the system and document the current uses.

Review and acceptance of requirements set

Design phase Produce documentation of the intended destination system. Make sure the features of the system map to the requirements from the previous milestone.

Review of the design with stakeholders

Migration planning/training phase

Construct a migration plan that includes technical activities, timelines, implementation steps and communication plans with users and executives. Train your users on the new system and conduct outreach.

Migration plan review with stakeholders and users

Test phase Set up some users on the destination system with test data. Document the usage results and collect feedback. Test the migration with data from the source system.

Migration test review with stakeholders

Migration phase Migrate the system. Migration completion review

User orientation, project completion phase

Continue to educate your users on the new system and conduct final outreach.

Project completion review

Share:

7

paper are almost exactly the same here. You will use the same processes to engage your users and collect the same information. Connect with your star players, political powerhouses and stakeholders to determine what is most important to them.

Know your environmentRequirement analysis for IT projects is a dark art. Many IT organizations think they understand the needs of their users. I often find that users and the IT organization supporting them are disconnected on how SharePoint is used in the business. This is why it’s important to meet with them and understand what they’re doing with SharePoint today and how they would like to work with it in the future.

Take an inventory of your current system. Understand the business processes and operational duties in your system and make very detailed notes on the possible impacts of moving to Office 365. For instance, you may have a process to analyze system logs every morning to check if a workflow has been operating correctly. Office 365 does not provide access to the system logs so this procedure for the operations staff will change.

Here’s a very important list of items to consider when taking inventory of your SharePoint system. These items or features may be in use on your internal SharePoint farm. Moving to Office 365 could impact them. Consider the use of Dell Software’s Site Administrator for SharePoint to assist in collecting this data.• Server-side data connections that may

not work properly—If you’re planning to

move your infrastructure to the cloud there

is a good chance that servers in your local

network will not be able to communicate

with Office 365. Know which servers will

be impacted and communicate with

those users.

• Document versions—A lot of folks use

document versioning, so take a good look

at its use in your environment. As part of

your migration, decide whether to keep all

of the versions, some of the versions, or

none of the versions.

• Alerts—Almost everyone uses alerts to

some degree. Verify the use of alerts and its

impact on the environment if they are an

issue during migration.

• Incoming email on document libraries—

Another favorite SharePoint feature

is incoming email. Consider whether

incoming email on document libraries will

still be required on Office 365. There’s a lot

to think about there, so plan time to study

this issue.

• Web parts—Are all of your web parts out of

the box? If there are any third-party web

parts, be sure they are compatible with

your new Office 365 farm. Verify there are

Office 365 counterparts on the Microsoft

SharePoint App Store or consider the

possibility that they may have to go away.

If the web parts are important enough to

your business, this may justify the decision

to go with a hybrid implementation.

• Farm solutions—Third-party farm solutions

are a similar story. You’ll have to find out

if there are Office 365 versions of these

solutions available. If not, consider a

hybrid farm if they are crucial to your

business. Just a note here – you may

have farm solutions in use that you didn’t

know existed. Dell Site Administrator for

SharePoint can assist with finding them.

• Web customizations (CSS, master pages,

page layouts)—I’m not going to lie to you

here. If you have a lot of customizations

on your local SharePoint farm they will be

challenging to migrate to Office 365. You

will not have access to the TEMPLATES or

LAYOUTS folder directly. Think really hard

about these custom bits and decide if they

are required.

• Content types—Some migration

approaches may not preserve any extra

content types you have in your farm. Take

an inventory of the content types in use on

your SharePoint farm and study whether or

not your preferred migration method will

assist with migrating them. Dell Migration

Suite for SharePoint is a good option here.

• Custom site and list definitions—Custom

site and list definitions can be challenging

to migrate. Seek to understand the use of

custom site and list definitions so you can

control them.

Many IT organizations think they understand the needs of their users. I often find that users and the IT organization supporting them are disconnected on how SharePoint is used in the business.

Share:

8

• Custom search scopes—Search scopes

rarely migrate, so include a plan to

reestablish them as part of your

migration plan.

• Content sources—Content sources may

have been established and forgotten

during the lifetime of your SharePoint

farm. Make sure to ask your site collection

administrators and users whether there

are content sources being indexed that

you may not know about. If your content

sources are anything other than SharePoint

sites, they will no longer be accessible

in a pure Office 365 environment. You

may have to implement a hybrid farm to

preserve the ability to search that content.

• Custom field types—Take note of any

special custom field types in your

environment. They may be lurking where

you do not expect – and they may not

migrate well!

• Custom crawler impact rules/crawl

schedules—You’ll need to write down

the custom crawl schedules and impact

rules that are used in your environment.

You will have zero control over these

options in a pure Office 365 environment.

Again, this may be an area where a hybrid

implementation is required.

• iFilters that exist on the source that need

to be on the destination—iFilters are a

separate installation. Know which iFilters

you have and find out if there is an Office

365 equivalent.

• InfoPath forms—InfoPath forms are an

interesting situation. Most of them may

work in a pure Office 365 environment, but

if they connect to external data sources

you’re going to be out of luck.

• Authentication in current farm—Does

your authentication scheme jive with

the capabilities of Office 365? Do you

need to implement Active Directory

synchronization in your environment to

preserve single sign-on? If so, you may

find yourself working on a project with the

Active Directory group before you begin

the migration to Office 365.

• Custom navigation—Verify the use of

custom navigation in your environment and

plan accordingly. If the custom navigation

proves to be problematic in the destination

environment, you’ll need to know details of

what to recreate.

• Incoming content feeds or automation—

Take inventory of the content feeds in your

environment. There’s a good chance those

incoming feeds will not operate in a pure

Office 365 environment! You may have to

maintain a hybrid environment here as well.

• Multiple language packs—If you are using

multiple language packs on SharePoint,

take note. Office 365 has multiple language

packs installed, but you may need to adjust

the settings on the site collections once the

migration is completed.

• Workflows—Workflows are a fantastic

feature of SharePoint. Consider the

three types of workflows: out of the box,

SharePoint Designer and Visual Studio

workflows. Make sure that you understand

how each is used and make plans to

deal with them if they misbehave in the

new environment. Be sure to include this

information in your migration plan.

If possible, test these workflows and

research the impact before migrating to

Office 365. This is yet another chokepoint

where a hybrid implementation becomes

a requirement.

• Other custom code solutions—You

may have enjoyed a staff of SharePoint

developers who created a vast array of

event listeners or other .NET code to plug

in to your SharePoint farm. Are they still

on staff? Will their code work in Office

365? If there is no App Store equivalent of

the code, you will be subjected to a code

review process before Microsoft will allow

it on a shared Office 365 instance.

• Network considerations—Consider all of

the elements of network connectivity, such

as subnets, VLANs, firewalls, load balancers

and the use of SSL offloading. How will they

impact your migration or the new farm?

• Backups—Are your backups healthy? I sure

hope so. If you have to punt the migration

project you will want this data handy. After

you migrate to Office 365 Microsoft will be

handling your backups unless you have a

hybrid deployment.

There is one crucial difference. If you’re migrating from on-premises SharePoint to Office 365, you should be aware that Office 365 places significant restrictions on the type of custom code that can be implemented. Microsoft has a number

InfoPath forms are an interesting situation. Most of them may work in a pure Office 365 environment, but if they connect to external data sources you’re going to be out of luck.

Share:

9

of certified solutions that can assist, but if your on-premises SharePoint deployment contains a large number of custom or third-party solutions, you may be in for a wild ride.

Many approved solutions are included in the Microsoft SharePoint App Store. This online marketplace contains solutions and third-party applications that have been approved for use with Office 365. There may be a situation where you discover that a custom solution in your on-premises deployment does not have an equivalent version in the App Store. If you stumble on this situation, don’t panic. First, determine whether or not the third-party application is still required. If it is, then you need to log the requirement and make sure to address it in the design phase. You’ll either address it by adding a feature to replicate the functionality or remove the use of the feature. Either way, you’ll be logging the requirement in this phase and its disposition in the next phase.

Another crucial step toward understanding your current system is to take inventory of your documents. You might want to consider installing

Dell’s Site Administrator for SharePoint. Site Administrator performs a thorough inventory of your system and provides graphs of usage. This will help you determine sites that need to be migrated first or last. Perhaps you’ll discover that some content hasn’t been used in years and can be removed entirely. Now is a great time to collect that information so it can be documented and included in the design phase.

Know your usersAfter you’ve taken a good look at the content in your environment, it’s time to talk to your users. They are the ones working with SharePoint every day, and they will make your journey a success or a failure. It is in your best interest to talk with them early and often. Make them feel involved in the future of the server architecture. It will benefit you tremendously.

Identify the users that will provide the most feedback. Get them into a room and ask them a pre-defined set of questions. Some examples:• How do you use SharePoint?

• How is SharePoint required for your day

to day activities?

The Site Collections report in Site Administrator for SharePoint identifies little- used sites to be cleaned up before migration.

Site Administrator performs a thorough inventory of your system and provides graphs of usage. This will help you determine sites that need to be migrated first or last.

Share:

10

• What do you like and dislike

about SharePoint?

• What do you think SharePoint could

do better?

• What have you always wanted to do with

SharePoint, but were afraid to ask?

• If SharePoint had a meltdown tomorrow,

could you still do your job?

There’s no right answer to the question and it’s not an interview. These questions are designed to get your users talking. Have more than one of them in the room and you’ll get a good discussion started. Another fancy trick is to take representatives from two groups or departments that do not work together directly, but both use SharePoint. Often you’ll find that the two groups will exchange ideas that are relevant to how SharePoint will operate for your business tomorrow.

Milestone: migration reviewAfter you figure out the requirements, log them into a table. An Excel spreadsheet would even be sufficient. Take the time to rate your requirements. Be sure you understand which requirements are the most important in the project; those are the ones to focus on when designing your finished product.

After you’ve written all of the requirements, present them to the stakeholders. Once they’ve come to an agreement on these requirements, ensure they understand that the requirements table will define the design but not everything is a priority. Sometimes this meeting results in an interesting debate. You can even use this debate to learn more about your requirements.

Design phaseNow you’ll be heads-down, working away on thoughts and reading web pages to understand your destination. Don’t spend too much time worrying about how you’ll get there. Right now you just need to understand how the finished system will look.

If you’re lucky, you’ll get to replicate the libraries and document collaboration features directly in Office 365. That will be a rare situation, however. You may also want to take this opportunity to restructure your information architecture, or how the content is organized. You may have discovered during the requirement collection phase that your information architecture is inadequate for your business needs. Now is a great time to address that issue.

It’s also time to address any third-party solutions that had been identified during requirement collection. Some of those third-party solutions may also work with Office 365. If not, you may find yourself in a bit of a bind. You’ll have to find a solution that replicates the functionality, remove the functionality, or consider a hybrid SharePoint farm to support your needs. Remember to balance the costs of your overall solution with the savings expectation of your superiors. Look back at the list of costs earlier in this paper and validate where you’ll be saving money if you go the hybrid route.

No information technology project is without risks. The design document needs to list out all potential risks and issues that could occur with the implementation. These risks should be mitigated if possible. Issues are usually confirmed to exist in the environment and may or may not be resolvable in the project. Make sure those are documented and understood.

Pull all of this information into a single package. This will be your “design document.” This document is meant to describe the end state of the solution. Make it easy to read and understand from start to finish. Don’t be afraid to include the requirements you collected from the earlier milestone to justify your decisions.

Milestone: design reviewCall up the stakeholders for another meeting. They may moan and groan about being called out to meet yet again, but it’s worth it in the long run. Create

Remember to balance the costs of your overall solution with the savings expectation of your superiors. Look back at the list of costs earlier in this paper and validate where you’ll be saving money if you go the hybrid route.

Share:

11

a PowerPoint deck that summarizes the high points of your design documentation. Make sure the story of the requirements mapping to design elements is clearly communicated. There should not be much room for debate here, unless you have options that need decisions from those in power. Be certain to go over the risks and issues that were identified in the design documentation, as your stakeholders need to be aware.

The expected outcome of this meeting is that your design package is blessed for implementation. Assuming this happens, you move on to the next phase of the project. It’s time to figure out how to get there.

Migration planning phaseThis phase will be used to map out the migration plan. There are many items to include in this plan. Some of them to think about:• Select your migration path

• Will you migrate with a third-party utility?

• Are you altering the Information

Architecture?

• If so, do you need to use a third-party

utility to manage it?

• Support model for your organization

• Does anything need to change on the

desktops? Does the help desk need

to assist?

• Communications/outreach to your

user community

• Make sure your users know what’s

going on and what they need to do.

Do not keep them in the dark. Be as

transparent as possible.

• What does success look like?

• Define success for your IT organization,

users and your stakeholders

TrainingYour users are likely going to need training. Each new revision of Office required an update to the user interface. Office 2013 and Office 365 are no different. Your users also need to understand that their data is stored in the cloud at this point. Part of your training plan may have included in-

house training or hiring a consultant. Either way, the training needs to occur.

Optimally, training should take place prior to the migration itself, but it can be challenging to execute training for users if the migration date is too far in the future, as users may find it confusing. The ultimate timeline decision is on you and what’s best for your organization.

Select your migration pathConsider your options for migration carefully. Many times you will find that requirements were identified that map to your migration options. Try to map those requirements to your options on a checklist. The requirements may have also dictated budgetary restrictions. This approach should help to identify whether or not you’ll want to use a third-party application, like Dell Migration Suite for SharePoint. Balance the costs of a third-party tool against the time you will spend migrating the content manually. Microsoft does not provide a native tool to migrate files into SharePoint Online, so you’ll be copying files by hand. In the case of migrating SharePoint data stored in lists (such as wikis, blogs, etc.), you’ll be using even more interesting methods to migrate content. Since you analyzed all of your requirements, you should have a firm understanding of the content and how you’ll get it there.

If you’re altering your environment’s information architecture, the native Office 365 tools aren’t going to help you much. Once the content is in Office 365, you will find it difficult to move. The use of a third-party utility is highly recommended in a situation like this because you will be able to reformat and restructure content, lists and sites on an as-needed basis.

Should you decide to go with a third-party utility, be sure to verify the support agreements with the software vendor. You wouldn’t want to be in the middle of the migration and run into a problem only to discover that the support agreement

Once the content is in Office 365, you will find it difficult to move. The use of a third-party utility is highly recommended in a situation like this because you will be able to reformat and restructure content, lists and sites on an as-needed basis.

Share:

12

expired. This needs to be considered as part of your overall budget allocation.

It’s also a good idea to think about pruning content prior to migration. There’s no reason to migrate data if it’s no longer needed. That data should be discovered during the requirements analysis phase. Migrating content that is no longer needed simply costs money. It requires time and network bandwidth to migrate. Why push it to Office 365 if it’s no longer needed?

Support model for your organizationA migration project like this makes all of the bugs in your system come out. You need to make sure your support staff is ready to assist. The help desk (if you have one) is your first line of defense when you’re in the thick of things. Make sure they are aware of the migration plan and timelines and they have adequate documentation on how to help the user community in case issues arise.

User communicationYou’ll need to communicate with your users. You’re about to move their cheese, so they really need to understand where it will be at the end of the project. You’ve already been training them, but you need to continue to communicate the project status as well. Your project may also be upgrading the version of SharePoint that they will be using. Will it impact their workflows? Did you have to remove or enhance any functionality they were using before? All of your requirement analysis should have identified these items and now it’s time to tell the users what will change. Your migration plan must address how you will communicate with the users. Will you communicate via email? Will you post information on bulletin boards in the common areas? Do you have any roadside billboards on your campus? Consider all of the options at your disposal. Communicate early and often. Waiting too late can cause significant unhappiness among your user community. Keep them informed and involved.

What does success look like?The migration plan should have a clearly defined goal that executives can understand. Make the goals measurable and realistic. Stakeholders love success stories, especially when they’re tangible and attainable. Write it out. Avoid using patriotic statements, but, at the same time, avoid negativity.

Milestone: present the migration plan to stakeholdersThe migration plan must contain the chosen method for migration, timelines, communication, training and testing plans. Use another “death by PowerPoint” meeting to hash out the finer points of the migration plan and provide the documentation. If the information is readily available, you’ll be surprised at the amount of participation and cooperation you receive from your executives, stakeholders and, most importantly, your users.

Test phaseIt’s time to test your migration plan. The best approach is to execute your documented migration plan as carefully and in as much detail as possible without impacting regular operations. You should be able to migrate copies of the data in-state without interrupting your users. This phase is intended to do that.

You will find problems. You will find solutions. You will use this phase to document all of those. Take note of what goes well and what doesn’t. If you selected users to assist with the test migration, collect their feedback. Document your findings and make sure to find resolutions to problems. These resolutions will be fed to your help desk and IT support staff. Some of the information may even make it to your users. Once again, this is where communication and transparency is a requirement.

Milestone: test review with stakeholdersThis milestone should present the findings in a clear format for your stakeholders. Be honest with them and verify that the

It’s also a good idea to think about pruning content prior to migration. There’s no reason to migrate data if it’s no longer needed. That data should be discovered during the requirements analysis phase.

Share:

13

plan is sound. If it’s not sound, that’s okay. Make sure that you paint the successes and failures. If your stakeholders detect that you’re avoiding the issues, they could turn on you. Your stakeholders must support you or you’ve lost.

After this milestone, the dates are set and the path is clear. You’re migrating and you know how you’re going to get there. It’s time to press the big red button.

Migration phaseThe day (or week, or month) has finally come. It’s time to actually perform the migration. Hopefully you’ve tested the migration plan line for line and this is really more of a performance with little to zero unknowns. You should communicate early and often, especially since your migration plan calls for it. There should be almost no undiscovered problems at this point.

Milestone: migration completion reviewThis review would be optional, but your stakeholders may appreciate the extra communication. Include all of the results in another slide deck and show off your success. You should be able to pull the list of success criteria that you defined earlier in the process and check off the boxes.Milestone: project completion reviewHave another review to tie up all loose ends with your stakeholders and executives. This is where you absolutely want to validate your success. Collect a list of lessons learned. Many of those lessons are organization items that can be used in another IT project elsewhere in the business. Executives love hearing about them.

Migration wrap-up

Your communication plan may have paved the way for improved outreach inside your organization. Since Office 365 uses a quarterly update model, that’s a huge benefit. You can now use these new communication methods and processes to talk with your users when Microsoft updates the service automatically for you. Your project blazed a trail for a new

relationship with your user community and your new service.

As mentioned earlier, if you decided to go with third-party tools, you can continue to use them to shift content around for users as a new operational service. Just because you’re finished with the migration doesn’t mean the tool’s usefulness is gone.

Congratulations on your successful migration to Office 365! Now you can use the power of the cloud for high availability, secure data storage and save money on the operations. Migration to a cloud service such as Office 365 may seem insurmountable, but it is ultimately a rewarding endeavor.

About the author

Jason Miller (MCSE, MCSA + Messaging, MCP, MCITP, MCTS) has more than 18 years of combined technology experience. Jason brings his skills to Summit 7 Systems to further his goals of building awesome, creative solutions to help customers improve their lives.

Jason was originally a theater major and computers were the hobby. Over time, the hobby became the love and he found himself living and breathing technology. Today he engineers anything from small projects to gargantuan enterprise behemoths Jason comes to Summit 7 Systems from NASA, where he was the chief engineer of the Agency-wide Messaging system based on Microsoft Exchange Server for 65,000 users. The project entailed many technological wonders from SharePoint and Office Communications Server to Mac and Linux as well. Prior to NASA, Jason helped the PEO-Aviation office at Redstone Arsenal achieve success in information technology.

Jason’s mental state is supported by his wife Yin and three hilarious, imaginative children.

As mentioned earlier, if you decided to go with third-party tools, you can continue to use them to shift content around for users as a new operational service. Just because you’re finished with the migration doesn’t mean the tool’s usefulness is gone.

Share:

14

Whitepaper-MigratingSharePointOnline-D-US-KS-2013-09-05

© 2013 Dell, Inc. ALL RIGHTS RESERVED. This document contains proprietary information protected by copyright. No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying and recording for any purpose without the written permission of Dell, Inc. (“Dell”).

Dell, Dell Software, the Dell Software logo and products—as identified in this document—are registered trademarks of Dell, Inc. in the U.S.A. and/or other countries. All other trademarks and registered trademarks are property of their respective owners.

The information in this document is provided in connection with Dell products. No license, express or implied, by estoppel or otherwise, to any intellectual property right is granted by this document or in connection with the sale of Dell products. EXCEPT AS SET FORTH IN DELL’S TERMS AND CONDITIONS AS SPECIFIED IN THE LICENSE AGREEMENT FOR THIS PRODUCT,

DELL ASSUMES NO LIABILITY WHATSOEVER AND DISCLAIMS ANY EXPRESS, IMPLIED OR STATUTORY WARRANTY RELATING TO ITS PRODUCTS INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. IN NO EVENT SHALL DELL BE LIABLE FOR ANY DIRECT, INDIRECT, CONSEQUENTIAL, PUNITIVE, SPECIAL OR INCIDENTAL DAMAGES (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF PROFITS, BUSINESS INTERRUPTION OR LOSS OF INFORMATION) ARISING OUT OF THE USE OR INABILITY TO USE THIS DOCUMENT, EVEN IF DELL HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Dell makes no representations or warranties with respect to the accuracy or completeness of the contents of this document and reserves the right to make changes to specifications and product descriptions at any time without notice. Dell does not make any commitment to update the information contained in this document.

About Dell SoftwareDell Software helps customers unlock greater potential through the power of technology—delivering scalable, affordable and simple-to-use solutions that simplify IT and mitigate risk. The Dell Software portfolio addresses five key areas of customer needs: data center and cloud management, information management, mobile workforce management, security and data protection. This software, when combined with Dell hardware and services, drives unmatched efficiency and productivity to accelerate business results. www.dellsoftware.com.

If you have any questions regarding your potential use of this material, contact:

Dell Software5 Polaris Way Aliso Viejo, CA 92656www.dellsoftware.comRefer to our Web site for regional and international office information.

For More Information

Share: