Posted on

There are a number of articles on our blog detailing what you need to know before you migrate to SharePoint 2016. We’ve also put together a full white paper to help guide you through the planning and execution of your migration project. But when running any large scale migration project – whether to SharePoint 2016 or beyond – nothing beats learning how to move successfully like chatting with a team of migration experts.

In the following webinar, four of our migration experts discuss the ins and outs of a SharePoint 2016 migration, as well as answer questions directly from the audience. Whether you’re ready to make the leap or are still wondering if migrating to SharePoint 2016 is the right move, learn what you can do now to adapt your business to the next era of SharePoint.

Have a question not covered in the webinar? Check out our list of SharePoint 2016 Frequently Asked Questions or ask it in a comment below!

Next Steps

For more advice on your SharePoint 2016 migration, download the Best Practices for Migrating to SharePoint 2016 White Paper – your prescriptive approach to planning, designing, and executing your migration project.

John Peluso: Hello, everybody. My name is John Peluso, and welcome to our webinar. So in this webinar, which is going to introduce some concepts around SharePoint 2016, we’re going to work through an agenda, and I’ve got a team here assembled with me who is going to help us understand some of the issues and give out some best practices about considering SharePoint 2016, as well as planning your migration.

So the first thing that we’ll do is talk a little bit about some of the reasons why people are considering SharePoint 2016. You may have heard some press about this. There’s lots of blogs that are out there. So we’ll discuss briefly some of the highlights and compelling factors around SharePoint 2016.

Then we’ll walk through a little bit of best practice advice about things you should be considering if you are really intending to move to SharePoint 2016. Some of those will be good best practices, no matter what SharePoint version you’re moving to, but some will be specific to SharePoint 2016.

We’ll talk a little bit about what your options are if you want to migrate from previous versions of SharePoint, or other systems into SharePoint 2016. We have a really neat section where the team here will bring their experience from the field on what they’ve seen in terms of best practices for ensuring that you’re going to have a smooth SharePoint 2016 migration.

We’ll finish up with a conversation about thinking about what happens after your SharePoint 2016 migration. So not only how to have the quickest, most efficient, and best experience migrating, but how to think about managing your SharePoint 2016 deployment even after you migrate.

So as I mentioned, I do have a pretty great team here with me. And so what I’m going to ask everyone to do is go ahead and introduce themselves. So I’ll start. My name is John Peluso. I’m a Senior Vice President of Product Strategy here at AvePoint. And my job is primarily to both talk with our customers, our potential customers, our current customers, find out what the needs are that are out in the market, what kinds of things they’re experiencing pain with, or looking to do from an optimization perspective. And then bring that information back and work with our internal development and engineering teams. So it’s a neat role that I get exposure to both sides.

And I’ll hand it off to Jasmine Floyd to introduce herself.

Jasmine Floyd: Hello, everybody. My name is Jasmine Floyd. I’m the Product Manager here at AvePoint. My primary focuses are our migration solution, as well as our governance automation solution. So my job here is I work really closely with John, with the items he brings out from the market, so that we can bring that information in and make great migration products for our customers.

John: Great. And Edmund?

Edmund White: Hi, everyone. I am Edmund White. I’m the Team Lead on the Account Technical Specialist Department. So that means that I run a team of sales engineers working with our mid-market customers to find good matches of where our AvePoint Software and services help them satisfy their business needs and goals.

John: Great. And then we also have Justin joining us today. Justin, why don’t you go ahead and introduce yourself?

Justin Walker: Hello, everybody, my name is Justin Walker. I’m a Senior Account Technical Specialist with AvePoint. Basically my role is to interface directly with the customer over the phone or onsite. Basically what I do is demonstrate how the AvePoint product suite can also allow the customers to benefit from all of the optimization in SharePoint that our AvePoint products offer.

John: Outstanding. Well, let’s go ahead and dive right in. I will say for folks in the audience, if you have questions, you can use the Q&A option in your webinar interface. So we’ll be collecting those questions and addressing them as we go through. We’ll find the best time to answer questions based on where we are in the topics. But please feel free to start loading up that question log. We really want to hear from you guys about what you’re thinking and what you’re wondering about with SharePoint 2016.

So the first thing I’ll do is just go quickly through a recap of some of the top features that we’re seeing interest in for SharePoint 2016. If some of you have missed it, we did a fairly extensive blog series on all of the areas that I’m about to review. So post this webinar, if you want to go back and get a little more detail on any of these things, simply go back and check that blog series.

But one area that we’re seeing interest in from a SharePoint 2016 perspective is some of the architecture improvements. So these are things that largely were borne in SharePoint Online. And then when Microsoft essentially brought the SharePoint Online offering back down to on-prem, we gained the benefit of a lot of the things that Microsoft learned that they had to do to operate SharePoint at scale.

And if you think about the effort of managing SharePoint Online, the sheer number of users and farms, there’s a lot of infrastructure that Microsoft realized it’s really hard to run SharePoint at that scale. Some of our customers know this intimately, and Microsoft learned as well.

So the first thing is one that is a little mysterious. There’s a way that Microsoft is positioning a new server topology for SharePoint 2016. And they’re calling that “Min-role.” And what this is, essentially, you had your choice in previous versions about deciding which particular SharePoint services you wanted to run on which of your farm servers. And there was lots of detailed TechNet guides on if you want to have best performance and reliability in farms that look like this, then make sure that your service footprint looks like this.

What Microsoft realized is that all of that configuration and all of those decisions can be very daunting and complex. So what they did is they identified a core set of services or a series of service sets that make sense to run on particular boxes. And they called those min-roles, minimum roles, right?

And the goal is, at least from the Microsoft perspective, that each server plays one and only one role. And when you install SharePoint on that server and identify it as a particular role, all of the appropriate services will spin up. No extra services will be running on that server because Microsoft has diagnosed that the best possible performance and reliability is achieved with this specific set of services.

Even better, there’s an ongoing compliance mechanism so that if, for example, an admin should decide to spin up another service on that box, you’ll be able to see a compliance checker that says, “Hey, this min-role is now running another service, and that shouldn’t be allowed,” and there will be a way to revert.

So Min-role is a way to simplify your service architecture for SharePoint. The old options are still available. They created a Min-role called Custom role. So if you want to be able to install whatever services you want on a box for whatever reason, you can still do that.

But this new capability around Min-role is what’s going to allow, for example, the ability to do zero down-time patching. Zero down-time patching is what everybody really is looking for. Microsoft realized they couldn’t meet their 99.9% up-time SLA that they had for SharePoint if they had to take SharePoint offline to do monthly updates. So Min-role is a big part of zero down-time patching.

The caveat here, though, is that Min-role requires that you have, at minimum, four servers in your farm. But if you want fully redundant and zero down-time patching capabilities, that scales up very quickly to nine servers. So nine servers is the minimum in a SharePoint farm for 2016 that’s running a fully redundant Min-role and also capable of zero down-time patching. So it’ll make sense for some customers, for other customers it might not.

Some other key architecture improvements are integration with some of the latest updates in the OneDrive for Business sync client. Which brings us the ability to do things like 10 gigabyte file sizes instead of the old 2 gigabyte limit.

Another area that Microsoft is heavily investing in with SharePoint 2016 is in the hybrid connections. So we saw the first peek of the Hybrid Search Connector in SharePoint 2013, and this brings you a fully integrated result set in a SharePoint search that’s conducted against your online SharePoint. That includes, in line with that, all of your on-premises information as well. So this now extends into SharePoint 2016, and we can expect that Microsoft will make the majority, if not all of their hybrid investments, into SharePoint 2016 go forward.

The other things that we’re seeing are things like profile redirection. So that if you have an on-premises user, you can have their profile redirected to Office 365. The reason that’s key is the profile experience in SharePoint Online is significantly enhanced over this 2013 model. But those changes did not come down to the SharePoint on-prem release for 2016. The reason is that the profile experience is powered by Dell, which is not available online.

So Hybrid is another area that people are interested in. And if we move on to some stuff that will really interface end users a little more clearly, we see things like some of the usability enhancements. So things like more intuitive controls around sharing, and an improved mobile experience that you’ll find some detail on in that blog series.

So SharePoint now natively has a much better user experience if you’re browsing from a mobile device. I’ve done it from an Android phone, and the experience is actually very usable with what you get there. So previously, you would have been resorting to some third party products to get that functionality.

The other thing in terms of new features, there’s not much beyond the enhancements we’ve talked about. You do get new policies around DLP and document retention. It looks like what we’re getting in the 2016 release, at least at launch, is going to be some very basic functionality for both of these areas. So again, tune into the blog series if you want a little bit more information about that. But these are the primary things that we’ve seen customers are interested in when considering 2016.

So let me pause and actually throw out to the team here, as you guys talk to customers, what is it that you’re finding customers interested in in SharePoint 2016? What are the most compelling things that they’re seeing?

Edmund: I’ll jump in there. The conversations that I’ve had so far have been around hybrid. We’re seeing about half of our customer base with some sort of hybrid profile. So what’s very exciting is the shared services aspect, being able to take advantage of the cloud for what the cloud is good at. That might be serving indexes or serving video portals, and taking advantage of what on-prem is good at as well.

John: Yeah, I think that hybrid is obviously a big bet that Microsoft is making with SharePoint 2016. One of the reasons being…obviously, it’s a competitive differentiator for them and they also know that at least for the short term, most of their customers will need that kind of on-premises capability, even if it’s just because they don’t have the capability of moving all of their legacy applications. And if you’ve played with it at all, we know that hybrid can be a confusing experience for customers. So SharePoint 2016 certainly tries to address that.

That was great. What else have you guys heard out there in the field?

Justin: Sure, I’ll step in.

Jasmine: I have to say the improved user experience, like we have here on the slides, definitely the increased collaborative effort. So because SharePoint 2016 is going to rely on that backbone of Office 365, it’s introducing a lot of those sharing, bringing that collaboration to be much more user-friendly from both an internal as well as an external platform.

John: Great. And Justin, you had something as well, correct?

Justin: Yeah, I did. I was out at a large customer in St. Louis just last week, and one of the big things that they were concerned about was the support for mobile. It was very large for them. And also, the integration with the search service in and of itself. Like you said earlier, being able to integrate both O365 and on-premises search is something that’s very large for a lot of customers.

And finally one of the things that was also mentioned in that meeting was information rights management, and really the security around OneDrive and how to work with external partners within the OneDrive environment. That’s some of the stuff that I’m seeing out there live in the field at this point.

John: Right. It totally makes sense. Good. So just keeping an eye on the questions in the Q&A, and there’s some comments about audio quality. So please keep those coming. If the audio quality is better or worse at times, just go ahead and keep that feedback coming, if you have it. We do have some folks monitoring on our side, and they’re experiencing good audio quality. So if you’re having problems, just let us know so that we’re aware.

There’s another question out there about the scope of this webcast and whether it will cover SharePoint Online or just SharePoint on-prem. I’ll say that the majority of the concepts that we’re going to present about SharePoint 2016 migration and management will apply to both, but we will be making sure that we make some statements about SharePoint on-prem and 2016 as well. That will be a major focus.

One more question, and I’ll take it now because it’s about infrastructure and architecture, and the question is about content databases. And so the guidance growing from the classic 200 gigabytes content database and recommendations that the content database can now grow up to 1 terabyte. The question is, “What is the optimized size?”

And that’s actually not a new change with SharePoint 2016, and even under SharePoint 2013. With certain workloads, Microsoft said that content databases could grow large. Especially what you want to think about there is if you’re looking to optimize the content database, the size that you’re targeting should really depend on the usage of the content within that database.

So if it’s highly active content, lots of edits, you’re going to want to still keep those databases a little bit smaller. If it’s archived content, content that is not going to be accessed frequently, typically record centers might look this way, then certainly moving up closer to that larger 1 terabyte limit is something that Microsoft will support you on.

Two words of caution, though. Remember that regardless of how big you can grow a content database, you want to still think about the efforts when it’s going to be time to migrate. If you plan on migrating to a future on-prem version and you’re contemplating doing a content database attach migration, the larger your content database, obviously, the more complicated that operation is going to be. Also think about how you’re doing backups and recoveries because larger content databases will just generally take up more time as well.

Good. So keep those questions and we will continue to field them. Anybody on the panel here have any other comments before we move on to talking specifically about SharePoint 2016 migration?

Justin: Hey, John, I do, this is Justin here. Just one other thing. Another thing that I’m seeing a lot of, and obviously with the cloud, I’m sure everybody out there in the field has this concern at the business level, and that is how are we actually going to be securing our environment from risk? And I think the ability to identify and search for sensitive content in O365, which is a new feature in 2016, is something that is going to be a benefit for many users out there.

John: Yeah, you’re going to want to take a look at those features. Certainly the introduction of things like content retention policies and DLP policies, those things are certainly a welcome addition to the SharePoint on-prem installation. One thing that you’re going to want to do is, very early, start to get a look at what that looks like on the ground.

You’ll notice, for example, at least in the Release Candidate of SharePoint 2016, you don’t get any capability around roll-up reporting of DLP incidents or anything like that. So it’s fairly basic. And so just make sure that that is a capability that you’re aware of. And if that’s not enough, then obviously you can look for solutions, and SharePoint certainly has them, that shore up those gaps.

The reason I think you’re seeing much less capability on-prem and you see Online is that they’re building a compliance center in SharePoint Online as a cross-service interface, whereas in SharePoint on-prem, they don’t really have that same capability. So just be aware of that as well. But definitely a good point there, Justin, as well.

Okay, so moving on, let’s talk a little bit about SharePoint 2016 migration. And we know that in any SharePoint 2016 migration, there are both technical and business challenges. So what I’m going to do is I’m going to turn this slide up here, and then we’ll have the panel weigh in.

But when we think about technical challenges for a SharePoint 2016 migration, any migration, but as most of our minds are right now specifically looking to SharePoint 2016, we see things like the ability to understand what you have on your source, the ability to figure out how you’re going to optimize the data transmission and the data movement for a SharePoint 2016 migration.

We know that there are, depending upon the version of SharePoint you’re moving, you may have legacy customizations, or there may be deprecated features, for example, if you’re a SharePoint 2010 customer and you were leveraging the Meeting Workspace. The Meeting Workspace no longer exists in SharePoint 2016. So transformation or conversion of objects is something that you’re going to want to think about.

And then one thing that we see a lot of our larger partners and clients, especially consulting organizations think about, is the validation at the end of a SharePoint 2016 migration is important. So that’s a technical challenge as well.

So let me throw it out to the panel on just the technical challenges that we’ve got loaded up here. What are you guys seeing, and potentially what best practice stories can you share about how some of our customers have approached these challenges and come out the other end successful?

Justin: I’ll chime in there, this is Justin again. I’m sorry, go ahead.

John: Yeah, Justin, go ahead. You’ve got the stick.

Justin: Okay, sorry about that. So the larger customers that I’m working with, the enterprise level, 10,000, 20,000, 100,00 user implementations that I’m working with today, a lot of what their main concern is with migration is we’ve got terabytes of data that we need to migrate from 2007, 2010, 2013 up to the cloud or even on-prem. And the biggest concern they have is, “How important is all of the content that I already have? How do I understand what I already have before I start a migration?

That’s a very complicated topic. And one of the things I always recommend is obviously to employ some form of a tool to allow you to iterate across your parent content and find out what’s valuable, or what maybe hasn’t been used or accessed over time. And then making a determination about how or in what size blocks you want to migrate that content through. That’s one of the things that larger customers are looking at because their content sizes are so large.

John: Yeah, that’s a great point. And when we get to the SharePoint 2016 migration best practices, Justin, I’m going to ask you to talk again about that specifically because I had a couple of points that I wanted to try to flesh out when we get there. So that was great. Jasmine, you had something as well?

Jasmine: Yeah, just more on what Justin is saying there, just about that discovery phase, and how that becomes a pretty key role in the entire SharePoint 2016 migration project, as well as that information architecture. So especially when we’re migrating from older versions like SharePoint 2010, like John mentioned, we have deprecated features that we have to take into account, as well as just being able to map over those newly created infrastructure, things on the destination. So being able to analyze your content to see exactly what you have, so that you can prepare that migration to map over very seamlessly. That’s been a very key thing in especially large-scale migration projects.

Edmund: What I’ve seen in SharePoint migrations in general is, as opposed to it being just a major version upgrade for people, I see a lot of interest in using it as an opportunity to either restructure content, add a new workload, take advantage of new features, and it really becomes a project at that point.

So sometimes, I see timelines affected by taking on a lot as part of the migration. That might not necessarily be migration-related, but has to do with future use of the environment, restructuring of content, that sort of thing.

John: Yeah. So a question that I had for you guys, because it’s often one that comes up that’s a bit of an issue, and strictly, it’s an issue because some of the migration options, but object conversions. So things like I had maybe some custom site templates on my source, or maybe I had some sites or some libraries that had feature dependencies on my source, and I’m not going to have those same customization in my destination. This is going to become a problem when we talk about the native database and cache migration option. But what have you seen customers do to account for this on-prem?

And one other thing that factors into this is you saw in Microsoft’s best practice guidance, they really are discouraging you from using custom site templates. We went through the site definition route. We went through the web template route.

And now Microsoft is saying, “Deploy primarily out of box team sites, and then do whatever artifact deployment that you need to do to make them look and smell different over top,” because they want you to stay with those core, native templates. So in a case like this, let’s say I have lots of custom templates. How in a SharePoint 2016 migration could I bring myself more in compliance with that best guidance?

Justin: I’ll chime in those, this is Justin here. I think probably the first thing you want to do is to understand the content that’s limited within the environment itself. But again, when you’re talking about having templates from one environment to another, you really need a tool to be able to analyze what those differences are, and give you a report about what the customizations that you have are, and if in fact they’re going to move forward. And that’s something you want to know before you ever start the SharePoint 2016 migration. It’s not something you want to find out during the SharePoint 2016 migration.

John: Yep. And I think right along those lines, Justin, we’ll talk about both the discovery tools in the AvePoint migrators, as well as some of the mapping options that’ll help with that. So absolutely.

Let’s move from the technical challenges to more of the business challenges. The business challenges are things like what’s the impact going to be on my business users? What kind of down-time am I going to need to plan for? How am I going to educate customers or my internal users about what the new system is?

Now, the business challenges from a user adjustment perspective in this SharePoint 2016 migration are really going to depend, I think, a lot on what you’re coming from. If you’re doing a ’13 to SharePoint 2016 migration, the user impact, I think, is going to be minimal because the interfaces are very similar. But if you’re coming from earlier products, SharePoint 2010, SharePoint 2007 as an example, then the impact is going to be a bit greater.

So do you guys have any thoughts about some of the business challenges that you’ve seen out there in the field?

Edmund:
I jumped the gun on my comment before, but taking on more than what is included in just a strict technical SharePoint 2016 migration as part of the upgrade can lead to timeline and scoping creep in there.

Also, as kind of part of that, the data identification and legal ramifications, SharePoint is mature enough at this point that a lot of our customers have a significant amount of content in it. And we get into a situation where, for either legal reasons or business reasons, we don’t necessarily want to just move everything from one place to the other to upgrade it.

And that can add significantly to the workload of a SharePoint 2016 migration if we need to start to pry into what’s actually in that content, in the environment, and what the implications will be for that in a new environment in 2016.

John: Yeah, definitely. So one thing I wanted to point out, and this is a concern from previous migrations to SharePoint 2013, one of the really cool things that Microsoft allowed in a SharePoint 2013 migration was this concept of moving over your databases to the new farm, to the SharePoint 2013 farm.

Let’s say you had SharePoint 2010 content databases. In the native database attach migration mode for SharePoint 2013, what you could do is you could move those databases across, add them to SharePoint 2013, update the databases so that the SharePoint 2013 could recognize them, but not run the upgrades of all the site collections immediately. You could do that on a schedule that you defined. And the database upgrade was fairly quick, and this was a way to minimize the down-time of a migration from, let’s say, SharePoint 2010 to SharePoint 2013.

The other benefit was that if you had customization or if you had master pages that had the 2010 look and feel, you could maintain that until such time as you desire to take on the burden of doing the visual upgrade and training your users about the new interface.

Unfortunately in SharePoint 2016, that option no longer exists. The cool feature where you had both a ’14 and a ’15 hive in SharePoint 2013 and you could bring your databases across, but not upgrade site collections immediately, that doesn’t exist.

So all of this, it’s very important if you’re going from SharePoint 2013 to 2016, all of your site collections need to be in SharePoint 2013 mode before you move. And no longer do you have the option, if you’re a 2010 customer, to do this sort of partial migration. The reason there is obviously because SharePoint 2016 is only going to allow a direct migration from SharePoint 2013, only version back.

And that brings us to what we should probably talk about now, which is an understanding of what your options are if you want to migrate. And so the two options that are classically available to you, well, there’s three options, but one’s really stinky.

The really stinky one is you stand up a SharePoint 2016 farm, and then you tell your users, “Go ahead and drag and drop your content from the old one to the new one.” This is a pretty stinky option. All but the smallest environments because you’re going to lose lots and lots of metadata as your users drag files around.

And one of the most important things about your environment is understanding “When were documents created? When were they modified? Who modified them?” and all that kind of stuff. So we don’t really consider that initial option as being viable for a lot of folks.

Edmund: Or just start using it for new workloads and then mess with every version of SharePoint in your environment?

John: Yep, new only, and really not dealing with the legacy content. That’s okay as a short-term strategy, but probably not a long-term strategy.

So the next option that we have available is Microsoft’s standard “native” upgrade. A question I still get that I’m kind of surprised by, there is no such thing as an in-place upgrade for SharePoint. So you’re going to have to stand up a new farm, go out and get new hardware, stand up a new farm. You’re going to have to do that. Or you can run it obviously by setting up a new virtual machine.

But you’re going to have to stand up a new net, new SharePoint 2016 farm because the only supported native migration is the old database attach mode. And this is where we back up our SharePoint 2013 databases, we carry them across to SharePoint 2016, we mount them there, we upgrade the databases, and we upgrade the site collections. Only then will the users be able to move over and use the 2016 environment. But obviously after that, you’ve got a lot of validation you’ve got to do.

And the problem with this whole database at a time transition is that there can be lots of things that happen in the ’13 environment that you may need to account for on the destination. This doesn’t give you any option for a data transformation, for example.

If you had those old site templates that are deprecated, or if you had custom site templates that you’re not going to use on the destination, there’s no opportunity to adjust because we’re essentially taking a closed, taped up box, and moving it from our old house to our new house.

The other option is to do what’s called an item level migration. And in an item level migration, this is in the realm of third party products such as the AvePoint migrators. So basically third party products like ours, a migration at the item level, meaning we can choose to look at every single item that we’re migrating while we migrate it. And we can therefore perform some filtering, we can decide to leave old versions behind, we can decide to leave old sites behind, we can decide to transform things as we go from source to destination.

Obviously an item level migration is going to take a bit longer than a database attach migration. But it has this advantage of being able to take care of these transformations, and examine the content as it comes across.

One of the things that we’ve seen, and I’ll call on the field guys here to talk about, is I’ve seen a customer and sat across the table from them who went from a SharePoint 2003 to a SharePoint 2007, brought everything, to a SharePoint 2010, brought everything. And then was sitting there with years and years and years of content, and trying to now sift through it and decide how they were going to get this under control. So there is an option to use your SharePoint 2016 migration as a spring cleaning.

What have you guys seen out in the field about customers and their approach from a database attach perspective? Are you seeing lots of folks going with this? And when you do see it, what do those opportunities look like versus the non-database attach opportunities?

Justin: I’ll chime in there. So it’s interesting. Back in the days of 2007 and 2010, in my experience, having actually worked in the enterprise prior to my AvePoint life, I would say that the database attach method was something that consulting firms would recommend and try to undertake, and try to do that on their own, simply because it sounds very easy to detach and reattach, and then do an upgrade.

The flip side of that, though, is you really don’t have very much control in that model. And so what I’m seeing a lot is customers who are more apt to look at the filtering and the item level type of migration, so that they can do things like handling transformations and moving content on a scheduled methodology as well.

One of the benefits of our tools that I really love, actually having done migrations in the past without tools, is that you have the notion of having your source and your destination environment in view, running a migration on a specific area or inside the SharePoint hierarchy, and then also capturing incremental changes as you are within the migration cycle.

So it’s nice to be able to have the item level fidelity that we get by using that model. And it’s also nice to not to force your user community to automatically switch over to some new platform without sampling them with access to the new platform prior to it actually being live in production. So that’s the stuff that I’ve seen out there, and it’s much more common now to do the item level.

John: Yeah. And I was going to say as well, the database attach, one of the things, the discussions I normally have with customers is, “Are you completely happy with your current information architecture, your current data density, the current quality of the content that’s in your site?” If the answer is no to any of those, then the database attach isn’t going to fix the problem.

Now, if you have a lot of items and you want to most quickly get from your old to your new, then certainly you could do a database attach. But it doesn’t have to be an and or an or. You can decide, “Hey, for some fairly vanilla site collections that have just standard user content in it, maybe we’ll do some database attach for those, but then we’ll do item-level for the areas that are trickier.”

And when we get into a discussion of the phases of a SharePoint 2016 migration, this is where that discovery phase is so important, trying to figure out what the right option is. The other thing I’ll just bring up real quickly is that a big reason why most people don’t do a native migration is simply the hard and fast limit that you only can do a native database attach from the previous SharePoint version. So if you’re a 2010, or if you’re a 2007, or even a 2003 customer, database attach isn’t even an option for you.

So some customers that are right now thinking about, “Hmm, how would I get there? If I’m on 2010, does it make sense to do a migration to 2013, and then do another migration to 2016?” The only thing worse than a migration project, from my mind, is two migration projects. So the ability to go directly from a previous version that is not the last one that Microsoft put out is a big benefit of the item level migrations. So that’s the other one there.

Let’s actually get into a conversation about actually running this migration project, and running it with the DocAve Software. So basically we’ve been talking about steps here. And we’ll try to get the animation to play fair here in the webinar platform. So the first thing…and I’ll just talk you through because it doesn’t seem like our animations are building, the first step is a discovery step. So in the discovery step, we really do need to make sure we analyze what is out on that source.

Let’s go ahead and throw this out. Justin and Edmund, you guys work out in the field with customers all the time. What is it that you are trying to accomplish in this discovery of the source environment, and how are you doing this?

Edmund: Yes, I can hop in there. On small projects, especially on large ones, this becomes essential. But even on small projects, the going in blind to them is never a good idea, even if you’re going to do a database detach/re-attach. Microsoft, in the past, has provided pre-check tools. They even understand how important this stage is.

With item level, we get a bit more granularity, a bit more insight into that. We can go very granular, look at sizes, types, customizations. Get a good profile on what the existing environment is, which is often something that isn’t done in between migrations in general. It can give us an idea on how fresh content is, what percentage of our content is fresh versus stale. The valuable exercise to do, and that sets the tone for the whole SharePoint 2016 migration, essentially.

John: Yeah, absolutely. Obviously in providing purpose-built discovery tools as part of our solution, this is an area that I know that we’ve been investing in significantly over the last couple years. Justin, what are you seeing out in your engagements?

Justin: Yeah. One of the things that I’m experiencing a lot with, again, the enterprise customers is some of these organizations are doing M&A. They’re doing mergers and acquisitions. And that becomes very interesting when you talk about migrating another corporation’s content into your own SharePoint environment, or into a position where they can at least access some of the resources in a SharePoint environment.

And one of the things that I love about our products is that we give you the ability to handle those discrepancies in between two corporations as part of the migration engine. And what I mean by that is let’s just think of domain users that are inside a source environment that are now going to become members of your destination environment. Well, those usernames are going to be the same, but their domain names are no longer the same.

And one of the beautiful things about the AvePoint product suite is we actually give you the ability to map the difference between the source domain and the new domain when you’re moving users. So just one of the things that I actually see out there on a regular basis is when you’re acquiring someone else’s farm and you’re doing the SharePoint 2016 migration, as opposed to migrating all the content that is in your own corporation’s environment. You still have a lot of granularity in the way you can map those deltas with the AvePoint product suite.

John: Yeah, absolutely. The phrase I use with customers all the time is that “A solution like ours will allow you to provide fidelity of the content in the migration as much as you want it, but transformation of that content where you don’t.” So we’ll make sure that all of the metadata and all the content types, and everything else mapped across properly, if that’s what you want. But if you need to transform usernames, domain names, content type mappings, site template mappings, we offer that capability as well.

I just see a quick question in the chat about SharePoint 2007 Discovery, and yeah, AvePoint does provide discovery tools for SharePoint 2007, 2010, and now 2013 as well through our discovery tool. And you’ll see similar capabilities for our other migration sources like eRooms, and file shares, and Lotus Notes, and Livelink and all that kind of good stuff. Evan, you want to pop that slide forward, or Edmund?

Based off of the discovery that you did, that is exactly what’s going to help you determine what kind of SharePoint 2016 migration you’re going to do, and what type of coexistence strategy you’re going to use. So the discovery may tell me, for example, again, these content databases, I’m seeing that I have primarily vanilla content. Pretty dense, but I’m okay with what’s in there. I don’t have a lot of old, stale versions, and I’m pretty much okay to bring it across with a lift and shift. Okay, maybe for those web applications, the content databases, you can do a database attach. But that doesn’t necessarily mean that you’re going to shift your users over that same weekend.

So one of the things that I love in our tool we added quite a bit ago, was this concept of a point-in-time incremental. And that allows us to do things like, “Hey, maybe I’ll do a content database for these site collections. I’ll do a database attach. But I’m going to spend some time validating that destination environment. So I’ll keep my users primarily on the old environment. And then nightly, what I’ll do is I’ll just simply do a migration of all the content that changed on my source over to my new environment to keep it fresh.” The fact that we didn’t do the original, full migration is really a trick of this point-in-time restore that you can get the same experience.

So even if you’re going to do a content database attach, it’s still useful to think about using an item level approach for your coexistence strategy. Certainly if you’re doing an item level for your entire SharePoint 2016 migration, these types of capabilities become absolutely useful.

The next step is to plan and build the information architecture, so this is what you’re going to have to do. If you’re using a product…a method like a content database attach, you’re, at minimum, going to have to stand up to your new farm. You’re going to have to stand up your web applications. And you’re going to have to stand up your service applications. Then you can start attaching your databases.

If you are doing an item level SharePoint 2016 migration and you’re using the AvePoint product, you’re going to have to do those same things. You don’t necessarily have to go any further. Because as we bring across site collections, we will create those new site collections on the fly. You don’t have to map those all out.

I will say, though, that if you found in your discovery that you want to do a lot of infrastructure architecture or information architecture restructuring, then this gives you the opportunity to create your new web applications, create your new site collection distribution first, and then move things into those as you go. So lots of flexibility there if you’re using a tool.

Mappings and filtering is something that we have talked through. So I think if we go through – guys, correct me if I’m wrong – but we do site template mapping, we do list template mapping, we do user mapping, domain mapping, content type mapping. So there’s quite a bit of mapping that can happen as you do this.

And the other things that are really useful are the filters. So can one of you guys talk us through the concept of what a DocAve filter policy is, and where it can be useful in a SharePoint 2016 migration?

Jasmine: Sure. Like you said, we have several filter policies that we have. One filter policy that a lot of users use which goes right back into that discovery phase, would maybe be a filter policy at the document level. So if during our discovery phase we found a large number of stale content things that haven’t been touched for quite some time, we can start the archiving process of those documents, but it’s no need for us to move that stuff over to our new, shiny destination.

So a filter policy that we could use there is a document level policy on our SharePoint 2016 migration plan that would say to DocAve, “Hey, any documents that have not been edited or had any type of action in the last four years, don’t move that as a part of my migration.” Some others that we’ve seen, back to the document level also, is for version control. So for some of those users that have those SharePoint 2007 and ’10 environments, we’ve been using them for years. A lot of our documents may have several versions of that one document.

So as a part of our data restriction policy, again, we can say, “Hey, DocAve, only bring over the last five major versions of that document.” So we use a filter policy there for that.

John: Yeah. The story I tell all the time is actually an internal story. I walked over to our tech writing team, and I saw that they were working on version 135 of a 10 megabyte user guide. So think about the sheer number of versions. And so, being able to be very flexible and say, “Filter out the last just five versions and bring those across, unless it’s this critical content type. And then bring everything.” So that kind of flexibility is really useful.

A question that we’re getting in the Q&A is around version support in DocAve 6 to migrate to SharePoint 2016. So in DocAve 6.7, Service Pack 7, which will be coming out shortly, we have the ability to migrate from SharePoint 2007, 2010, 2013. Your destinations can be 2013, 2016, and SharePoint Online. So source ’07, ’10, ’13. Destination, ’13, ’16, SharePoint Online. So hopefully, that one got that one.

We got some other good ones here. “Does the AvePoint migration product allow us to split a large site collection into multiple sub-site collections during the migration process?” Yeah, we can do that and we do it on the fly, actually. You can simply look at your source, say, “Hey, I want to take these items from the overloaded site collection and migrate it into this new site collection.” We can even provision that site collection on the destination on the fly. And the tool will allow you to do all those restructurings right from the interface there, so it makes it better.

There’s some questions that have come in on step by steps for setting up the cloud, the hybrid search appliance. TechNet is going to be your best bet on those, but check our blogs because I’m sure we’ve got links to them.

Let’s keep going through this. The next and most important part here is smoke tests. Your smoke tests are going to allow you to test out the plans and the jobs that you’ve created, and SharePoint 2016 migration is an iterative process. It always is an iterative process. You’re going to do some smoke tests. If you need to, you’re going to revise, you’re going to iterate. This is useful as well, because you’ll get a sense of things like your SharePoint 2016 migration speed, what are you getting in terms of throughput. Do you need to do some optimizations?

One of the things that we classically do…and Justin or Edmund can probably talk us through the concept of a scaled out SharePoint 2016 migration. Basically because DocAve runs as a centralized piece of software, we can, by leveraging multiple DocAve agents, dramatically decrease the time that we take to do a SharePoint 2016 migration when it’s just sheer data moving. So can Justin or Edmund, can one of you guys talk us through the concept of a migration factory?

Justin: Sure, I’ll chime in there. Basically, what we’re talking about there is the notion of agent groups. And what we’re saying when we discuss this is basically that let’s say you have a large set of content that you need to migrate, and you’ve got an extremely large farm of web front ends out there that you need to move content through. Through the DocAve platform, what we can do is we can create our own group of agents that will run specifically dedicated to the migration operation, without placing any overhead on the existing SharePoint environment and/or the live users.

So we do give you the ability to actually partition different agents running within your environment, so that we can place the load of the migration itself in an isolated area, so that the migration of content is smooth and also occurring in the background.

John: Yep, definitely. The last step here is to do that migration. But actually, that’s not the last step, right? The last step is to do your validation of the migration. And this is often a requirement, especially when the migration is being done via a third party or something like this. So Edmund, can you talk us through a little bit the kinds of validation that customers and partners ask us for, and how we satisfy that with some of the features of the tool?

Edmund: Yeah, absolutely. So a very common request when you’re doing item level migration is simply for a report of every item that you migrated, which is an output that we provide. There’s often a user acceptance testing aspect of that as well. When that comes into play, the incremental SharePoint 2016 migration that John was speaking about earlier is very helpful. It allows us to hold off that cut-over until the destination environment is fully thought through.

The other thing that I wanted to bring up before we move off this slide is that since migrations are a once every year or two activity, it is an important activity for SharePoint admins. What we’re seeing more and more is companies coming to us and looking for our expertise in the migration field. Since we do them on a daily basis, and most organizations only do them on a year or two year basis. So we actually do have the capabilities to come in and do the entire migration, and we’re seeing a lot of people finding value in them.

John: Yeah, especially when it’s a large data set, you see that as well. So the last thing I’ll add on the validation side of this is the need to understand what was moved. And especially when you’re doing a lot of individual migration jobs at lower levels, it can be tough to sort of sift through tons and tons of different job reports.

So one of the features that we added a few versions ago that really helps out with this is a feature called the Migration Database. What this does is it logs every single migration of every single item into a centralized database, so that you can use this information to create your end of migration validation reports. And we can say, “Hey, here are every single item that moved. Here’s when it moved. Here was the success or failure of the move,” and so forth and so on.

So let’s go on to that last step of the presentation here. This is one that I think we’ve got to spend at least a couple of minutes on at the close of this…and we haven’t even talked at all beyond focusing on the migration of how we are going to make sure that our SharePoint 2016 environment doesn’t go the way of so many other SharePoint environments that we’ve all seen over the years.

Chaos, in some sense, is the natural state of any SharePoint deployment left to its own devices. This is in for a lot of reasons, but partially, it speaks to the flexibility and the user capabilities within SharePoint to bend it into whatever they want. Sometimes, though, they can bend it into things that we don’t want them to bend it into.

What we want to do in those cases is really think about how we are going to manage things like permissions and content, and content life cycle after a migration. One of the things that we always make sure that we talk to customers about, is the migration is the project. That’s the getting it from A to B. But after that, you really are going to want to think about, “How am I going to manage this content go forward?”

So things like the ability to do periodic security searches, the ability to, “Okay, I left all those old versions behind, but how do I now mandate that we can’t create this mess again? I’m not going to collect 135 versions of a 10 megabyte file.” So being able to bring things like policy enforcement and infrastructure optimization, reporting and auditing; this is how we’re going to keep that SharePoint 2016 deployment from becoming a mess.

So we’re almost at the end of our time here, and I have a couple of questions that I think we still have unanswered. One question is about “Is the organization planning a complete 2016 upgrade to all Microsoft apps? What order should SharePoint be implemented?” If you asked that question, please go ahead and just give us a little bit more information about what you’re asking about. If you’re asking about, “Should I do the Office installation first and then the SharePoint installation?” I think that’s a smart way to go. But really, it’s going to depend more on the priorities within the organization.

If there’s an Exchange upgrade in there as well, generally, what we’ll see is that the client gets updated at the same time as the Exchange server. And then, potentially, the SharePoint server comes after. But give us a little more information about it, what you’re asking for there.

And then we also have a question around, “Does AvePoint’s product have the ability to move all the search configurations from 2013 to 2016 on-prem?” Again, if we can have a little bit more information there. I’m not sure if you’re asking about the included index setting of each library or site, or if you’re asking about, literally, the crawl to sources and content rules and so forth. Usually we move things like content sources and crawl rules. But you’re probably going to want to create them anyway on your destination, leveraging any new features that are in there, or new capabilities that you have. So again, more information there would be cool if you have it.

Good, so I think that the last question that we may want to leave this on is one that I have heard the most discussion about. “What is the difference between SharePoint 2013 and 2016? And if I’m already a SharePoint 2013 customer, is 2016 a compelling upgrade for me?” And maybe let’s just do a round table for what you guys think. But Justin, do you want to chime in first on your feelings on that one? Because I’ve heard lots of opinions on both sides.

Justin: Yeah, I think it really depends on what your requirements are for the new platform. Obviously, you need to keep yourself well within the supported lifespan of each of the products. So if you’re on ’13, it may make sense to stay on ’13, but you also need to have your eye towards the future, because there will be an expiration date on the level of support you’re receiving today in ’13.

There are a lot of new features in 2016 versus 2013, and really, that’s going to be the delineating factor is going to be “Is there a functionality that’s in ’16 that is going to give you immediate benefit in your environments?” And you also want to think about, “Are you going to have some type of a hybrid implementation? Are you planning to move all of your content to the cloud, or are you going to have some content still down on your on-prem environment?” Those are the things that you want to consider.

But it really depends on…look at all the new features on the list of features, and I’m sure that’s out there on TechNet, John. It really depends on what you’re really looking to do, and what you’re looking to gain by moving to the next version of the platform.

John: Yep, Edmund?

Edmund: I agree. It depends on what kind of organization you’re with, of course. We’ve seen this on previous upgrades. We’re going to see it again on this one. There’s going to be a lot of “Wait and see” this year and then a lot of movement next year. There’s going to be early adopters, there’s going to be a lot of information coming out.

I would say if I was thinking through this, I would look at the compelling features and the popularity of Office 365 and SharePoint Online, and be excited about getting some of that functionality on my on-prem environment without having to do a large architectural change into hybrid, or a more organizational-wide, impactful move. Versus just a simple SharePoint upgrade and get a lot of those features.

John: Yeah. I actually have a blog post that’s rolling out, I think it’s publishing today. And what I do in that blog post is I actually take a…it’s not specifically about SharePoint 2016, but it’s more about a consideration of a move to the cloud, but the concepts are the same.

I think that I agree both with Edmund and Justin that it absolutely has to be focused on the specific needs of the organization. So what you have to do is weigh what the potential benefit is. If you have a ton of mobile users, and an increase in the mobile experience is going to be a compelling business driver, then yeah, you might want to make that move from ’13 to ’16. If you’re going to be a hybrid customer and you’re going to want to take advantage of things like hybrid search and hybrid profile experiences, which you most likely are, then yeah, I would say definitely think about that upgrade to 2016.

If you’re fairly comfortable with your SharePoint deployment today, and you don’t have a big investment in mobile users, and you don’t really have an investment in SharePoint Online, you’re probably going to be okay to stay on SharePoint 2016 for the foreseeable future, I would say, with one caveat. All net new investments, all net new feature investments, we can expect will come in SharePoint 2016. And we haven’t gotten a solid answer on this, but Microsoft is hinting that those feature enhancements may come more frequently than your average three-year release cycle.

So if new features are something that’s important to you, remember that all of the innovation is going to happen on the latest platforms. I’ll say that I wouldn’t consider things like the DLP functionality. A compelling reason to upgrade from SharePoint 2013 doesn’t seem like it’s there yet.

Edmund: So if you’re a 2010 or 2007 customer and you just have been putting off a migration, or there isn’t really compelling reason to stay on that platform, I think 2016 would be a great opportunity to do that because of what John just said. That there is some security in future upgrades being in smaller increments, easier to manage. We’ve certainly had the up-time capabilities for patching. So that could be a really comfortable environment for you to move into.

John: Great. So I think we’re a few minutes over. I want to thank all the folks on the panel here. Greatly appreciate your expertise and participation. And I want to thank the huge list of attendees, so thank you, guys, for tuning in. Go ahead and investigate some of those blogs we mentioned, which are going to be on our websites, and we’ll provide links out to those if you need them.

And look out for future webinars that we’ve got planned. I know we’ve got a bunch of things planned in the near future around Office 365, specifically. So if you’re interested in that as well, please come back and join us.

So thanks for now, and we will see you next time.