So I fielded my first call this week by a client wanting to prepare for the migration from 2012 to 20??. So it brought back the memories of 2007 to 2010, even though many of us Consultants are actively working on migration, the pro-active request was Refreshing.
So I though I would take this post to discuss how to approach a migration and embrace this event…not fear it. Remember that for everyone you may have your favorite approach, however this is just to get your juices flowing.
So I like to a full audit of all the data I believe will be involved with the migration. This is a big task, and a moving target as new data will be introduced between the day I start this process and the go day. So consider doing this in layers, start with container identification and then classification of data in the containers. You can target specific file types as you move closer to the go day.
Pick a tool you like for this process, a access data base is usually a good start. Don’t go Excel, unless we are only taken a few thousand files, it will just get away from you.
My analysts like to start from excel, then build out the data cube once they get a better pictures of the effort. Now if you are as OCD as me you have this already in a SharePoint site that admins have been building since you went live with your last migration.
Now I am a big fan of Analysis without Paralysis, doing pre-scans, and audits are great and will give you intelligence into your data, but don’t spend so much time doing this that your stakeholders loose faith or attention.
Ownership: so one of the critical and biggest challenges is identifying owners of data. This is also where I usually start the process with the business. The biggest reason is this is the longest and usually the largest impact on business.
I have found that starting with the audit now gives me a visual aid when talking to the business. "A picture is worth my sanity!"
So you have this giant data matrix right, start adding tags to the data:
Who manages it?
Who owns it?
Who approves it?
Who consumes it?
Is it valid for migration? Yes you will find orphans along the way, but this is the only way to truly feel prepared. You do not go into a dark alley without a flashlight.
So you are looking to perform you migration, any I am betting you are looking to just buy a tool and point and shoot. First SharePoint Migrations are not Call of Duty, you have to do some work. Second unless you never customized your SharePoint, or heck absolutely trust your users….things are not going to work perfect.
I am not going to preach a tool, main reasons is well they all have problems, limitations, or were developed in a silo without YOUR environment being considered. I am not saying they don’t work, on the contrary my team, and many hot shot SharePoint Admins have been relying on them for a lot of tricky and challenging projects. What I am saying is don’t bet the farm on a tool to solve your problems.
I will say this, the minute you have a tool that can do this perfect, every time, there will be a lot of happy consultants that can stop having migraines every time a client wants to migrate. Now what is also to understand is a tool only is a part of the process, it can speed up the process, or automate some, HOWEVER a knowledgeable use of PowerShell and STSADM commands and you will achieve the same results.
So most folks want to do a migration in a coffee break….seriously. I have to say if you rush it or do not plan correctly you will only do one thing….FAIL. A basic migration will take about 50-80 hours of time. This includes our audit, pre-scans, review, build of new environment and prep, and the migration process itself. Now it is important to understand this is an ESTIMATE of time, not to be quoted as “Well Scott Said So”. If you do that, don’t blame me when you screw it up and miss your milestone.
You can only truly have a understanding of the migration timeline once you have completed the Audit and Pre-scan of the data. You could have a lot of challenges such as orphan data, corrupt DB’s, customization not documented, or just sites that are so Off Reservation you should kick the site admins butt. So lets take all the other factors out of this. What about the data itself.
If you are using a tool. I am going to quote The Divinci Migrator by Axceler “just because one of my teammates is using right now” he took 4 days to move 2-3 site collections over. Now he did take time focusing on Information Architecture, Content Types, Metadata, and documenting the New Environment. And these were only a few gigs, say 4-10 gb of data. Now if he had done this via script, say PowerShell you could cut that time by about 6-8 hours. WHAT? We used the tool as the client had it, trusted it, and wanted to also learn how to effectively use it in the future….so some Mentoring in that time. So do you see the time variable. This is why you can never in any situation say it will take exactly X Hours……come on this is SharePoint the minute you think you have something mastered someone comes down the street and shows you some other way to do it, or why you have been doing it wrong for 5 years. LOL.
OK, so now you have done all the leg work and you are ready to migrate, not so fast. Governance baby, you need to ensure you have policies, and governance around your new environment. To move your futon, and college stuff from one place to another is just bringing your old junk. You need to update, style, grow up…..sorry flashbacks. Now truthfully you have an opportunity if you have not already done so. A migration can be a fresh start, a chance to implement policy and rules that you could not do in your previous environment.
This can also give you the chance to say NO, to customization or business needs that will be impossible to support or maintain.
Make It So:
OK so just go do it. Done, great, had issues, welcome to the club. Welcome to the SharePoint Brotherhood. Moving on now.
So you have started to moving, train your folks on the new environment. This is a great chance to train your site admins, site contributors, and user support folks. If you can train them up on the new site, the transition will be easier.
I like to do a form or Quick Guides, or User Guides that I leverage as part of the migration plan. Show them what the site could be, or how it will be once migrated. Helps set proper expectations, and ensures a smoother transition.
Now we are done, now we need to deal with the after effects. What do I mean by after effects.
Orphan or Corrupt Data
Search not reacting correctly
SEO Wrong, 301 redirects not setup right
Security was not translated right
Look and Feel not working correctly
THE RIBBON, WHAT IS THE RIBBON
These are common questions I hear from blogs, discussion boards, twitter, and my email from organizations that are reaching out after another person migrated them. Be prepared to take an additional 40+ hours for each Business Unit you migrate to answer questions, and support them. It is like moving to another state or country, it can take time to navigation, understand your surroundings, and sometime learn the language. As a SharePoint Admin…get over it, it is what we do. Keep in mind we love SharePoint, to the users it is just another Application they have to use to get there job done.Now take your lessons learned from your first migration, wash rinse repeat. This is why I like to migrate a small Business Unit, or Site Collection first, get your sea legs, learn how to do it. I know a lot of folks that have done 4-5 entire company migrations, that are still getting the hang of it. It is a tricky process.
In Retrospect a lot of SharePoint Consultants, and Administrators see a migration as HELL WEEK for IT, and I do agree it can be very taxing on you nerves and budget. I do see this as an opportunity for your organization to also grow. You can implement Governance, Security Models, Audit Compliance, New Branding, Tools and Solutions, and Unify platforms. See it as a great chance you can embrace, and present it to your business as such. Plan, Plan, Plan, but do not paralyze yourself in the process. I can say that this is commonly one the best times to bring in professional consultants to do the work, or mentor your team thru the process. If you do, check references…please check them. Do not let a hack come in and destroy your chance, and spend your money giving you garbage.
Keep in mind also this is a point when a tool is only part of the solution, look at the full process, it is a Enterprise Platform, treat it as such. If you hear folks just saying we did it over a weekend, they did it wrong. As you can see there is more than just moving data, there is opportunity.
If you are considering this or doing this and the post is news to you….please email me and I will try and get you on the right path. Best Wishes and Keep Moving Forward.