Share and Enjoy !

Well hello folks, and welcome. John Underwood here and I’m happy to have you joining me for another day of SharePoint learning, and in this particular webinar, we’re going to talk a bit about migrations. I know that some of you have obviously been through these before in your past, when you’ve gone through previous versions of SharePoint, and today, we’re going to talk about the same sort of thing when it comes to moving to SharePoint 2013.

I won’t bore you with a lot about me. You can see my name and my position on the screen there. I would encourage you to take a moment and maybe scribble down my email address or my Twitter account feed there, just so that you can contact me later if you have any questions or issues.

All right, so what am I assuming about my audience today? Well, first up, I always assume I’ve got a blend of three different groups: managers, administrators and developers. For those of you that might be in the manager or business owner or user community, what I hope you get out of today is just a sense of what you’re going to have to do as part of the effort to get a migration done. Everybody’s going to have a role and it might be tempting for those of you in the business role to think, “Oh, I’m just going to sit back and let the IT people do this.”, but the truth is you’re a very important part and success really depends upon your involvement and your buy-in.

Next up, we’ll talk to administrators. It would be natural for an administrator to have some reluctance to do a migration. Let’s face it. It’s not an easy job so what I hope I can bring for the administrators today are just some ideas about tools and practices and patterns that we can employ to make the process a bit easier for you.

Then finally, we’ll talk a little bit about developers. Although this is not a coding webinar, and I’m not really going to be looking at any code samples, perhaps you have the toughest role of all developers because as we see, the move from SharePoint 2010 to SharePoint 2013, there’s some radical changes afoot for developers, and so if you are in that role, you’re going to want to understand what’s coming and the best way to respond to that.

Within that, I’m going to hit four topic areas. At first, I’m just going to explain migrations. What are they? What are they about? How is it going to affect you? Next, we’re going to talk a little bit about the cloud. Virtually every webinar I’ve done for the last 6 months had either total emphasis on the cloud or some kind of passing reference to it and the streak is going to remain intact here. The big deal on this is just where we’re going is going to affect what we do, so we have to talk about that in context of the cloud.

Then we’re going to be a little more specific on some things that we can bring to the table here at ThreeWill. As you’re going to see, we have a fairly mature migration process that we’ve used over a fairly long period of time, and so I just want to give you some highlights of what that might look like. Really, that would do two things for you. In a very general sense, it’s going to help you understand the sort of things that you need to be doing for a migration, and then beyond that, if you choose to engage ThreeWill to help you with the migration, then you’re just going to see a bit more about how the process might look.

Then I’m going to wind up our time together talking about code-based customizations. Those of you that are developers, while all of this is going to mean something to you, this is going to be the most important part. This is where we’re going to talk about the specifics of how we get your application moved.

All right, so if we were to take an incredibly simple view of the world when it comes to migrations, it would look something like this. We’ll go out and buy a tool that will migrate all of our data from an old system to a new system. We’ll click a button and then the migration is complete. Without casting a negative light on anyone, it might be tempting for those that are in a non-technical role to view this world this way, “Hey, we bought this really expensive tool and boom, it’s going to handle everything for us.”

This is rarely true in a general sense and it’s certainly rarely true when it comes to SharePoint. Then some of the big questions that are going to pop up, even if we are going to buy a migration tool, which one? Different ones had different specialties that may fit certain kinds of environments. You’ve got to make some kind of assessment of which one is actually going to be a fit for us.

Then okay, we just click a button and run it. Well, even the most sophisticated tools are going to require some work up front. It’s going to have to know some things about your environment in order for it to do what it does effectively.

Then finally, once the tool runs, unless you’re talking about a really, really simple SharePoint environment that’s maybe got 5 sites and a couple hundred documents, the output from the migration tool, there’s really just another step in the process. We’re going to have many more things to do once the migration tool has churned through its iteration.

Let’s see if we can take maybe a little more realistic look at how a migration would look. The analogy I like to use for this, it’s very similar to moving from one house to another. This is an analogy that’s going to resonate with a lot of you. A lot of you have been through this either professionally or personally. Things we have to think about when we’re moving from house to house. How far away is our destination? In more particular terms, where are we going? That is certainly going to have some kind of influence on what goes, what stays, what gets thrown out. Let’s face it, if you’re moving across town, it’s a pretty easy move and you’re moving to a bigger dwelling, you’re going to take everything, but if you’re moving to another continent or you’re moving to a smaller destination, you’re going to have to throw some things out.

Guess what, the same things are going to apply in the software world. If we’re moving from one system to another and that new system has different capabilities, there may be some things we can’t bring along, or we’re moving to a cloud environment and purely from an economic point of view, we’re moving from a big SharePoint dwelling on premise to maybe a small one online, so we’re going to have to figure out what goes, what gets thrown out.

Finally, this is the most challenging part of all. How well organized is the current dwelling? Now I won’t ask for a show of hands, but I’m going to bet that most of you, if you were to be honest about your current SharePoint installation, you’d say that it looks more like the garage on the left than it does like the garage on the right. Just as an aside, some folks from our workplace agree that the garage on the right was pretty cool and they’d love to have that.

Then as you go into this process, I hope you’ll have these pictures in your mind. If you have a really tightly well governed environment, your move is going to be simpler. If you’ve got an environment that has grown like the Ivy or if you’re in the south like the [inaudible 00:07:16] and it’s terribly unorganized, then sooner or later, you’re going to have to face the music on that and realize that that’s going to be a more daunting task when it comes to making the move.

Now in our specific example, obviously SharePoint 2013 is our destination, but that’s going to come in a couple of flavors. One would be that you’re going to host your own servers in SharePoint 2013 just as you’ve done in 2010. That would be on-premise. Another approach is to say, “We’re going to move to SharePoint 2013 but we’re going to move it to the cloud.”, and in this particular webinar, when I say cloud, I specifically mean SharePoint Online within the Microsoft 365 offering.

You may have tuned in to my previous webinar, and if so, you’ve heard me already talk about Hybrid. For those of you that didn’t get a chance to view that, Hybrid is just a way of saying that some enterprises are going to use both. They’re going to have On-premise for certain things and Cloud for certain things. Regardless of which one of these you choose or which blend you choose, the destination is going to affect every aspect of our conversion.

Even before we begin the planning process, we have to know where we’re going to go and that’s a big decision that your enterprise is going to have to make before taking on this journey.

Looking at some of the criteria on what stays, what goes, what gets thrown out. One thing to think about is obsolescence. We weren’t in an environment in SharePoint that encourages users to contribute content, there’s a really big risk that there’s going to be some content out there that’s simply obsolete. Again, I worked at places where people would put up ads for puppies or lunch room menus or a lot of things that might be interesting and useful at the time, but they don’t really have a long line.

Let’s face it. If your servers are on premise, the cost of maintaining the lunch room menu document from 2007 is very hard to see. It’s almost invisible, because let’s face it, the server’s there anyway. The hard drive’s there anyway and if you delete that document, it’s not going to make the hard drive spin any faster. However, when we think about going to the cloud, that is a different matter, because the cloud is a pay as you go environment. There’s going to be tangible cost associated with every single piece of data that you have there and all of the ways that you may access it.

Another thing that’s going to influence the migration is the frequency of use of a particular document. While we’ll talk about a little later some inventory tools that we have to help you assess your environment, just because something hasn’t been accessed for 2 years doesn’t mean it’s not important. It could be that there is a legal ramification of having a certain document and you’ve got to keep it around and keep it readily available, even though it only may get used once every few years.

Another thing to think about is legal or regulatory. This is somewhat relevant to the frequency of use thing, in that it’s age or how long it’s been since you’ve accessed it may not be affected at all if it’s a legally required document or something that has to do with regulations. Not only that, in some cases, there are specific laws that say certain documents have to be kept for a certain amount of time, and so we want to make sure as we begin to migrate to our environment that we keep these legal or regulatory requirements intact.

Then customizations, well I’m going to drill in to this much more deeply at the end of our presentation. For now, let me just give you the short version. This is really much going to be an effort versus value proposition, particularly if you’re moving to the cloud. You’re going to see that our choices are somewhat restricted there, and in that scenario, we may have a lot of work ahead of us, so more to come on that as we go along.

You remember my garage icons from a couple of slides ago. If we were to put those in more formal terms, the first of those would be governance. Do you have an effective governance policy in place, and by effective, I mean do you have a document and then do you actually enforce the document? I hope you have, but if you haven’t, then you’re really going to be forced to deal with this one way or another when it comes to your migration. Otherwise, you might begin to pay a lot of costs that you don’t really need or really want to pay, and again, we can do an entire webinar on governance. Let me just prompt you and encourage you. If you’re not doing the right thing here, a migration might have a silver lining in that it might be an opportunity for you to get your house in order and particularly on the post-migration side. That may be part of our criteria for moving from an old to new environment is to say, “We’re going to have a good governance policy and a good governance mechanism on the new environment and nothing goes there [inaudible 00:12:18].”

Another challenge that we have to deal with, SharePoint Sprawl. If your company has been undisciplined about the number of site collections or sites or sub-sites, I’ve worked at companies before where people didn’t realize that a site could have more than one library, and so every time they need a new library, they would create a new sub-site just for that library. At some level, a migration might be a chance to clean up some of that, and then obviously, avoiding SharePoint Sprawl in the future is going to be tied into having a good governance policy.

Then one of the items that’s hidden from view but is really, really important, and that is how neat or how dirty are your permissions on your site. If you followed generally accepted best practices on how you’ve set up your permissions, then you should have an easy go here, but unfortunately, what we see in a lot of companies is that someone with the authority to do so has gone in and broken permissions on a library, or even worse, they’ve got a library where they’ve set individual permissions on documents in these libraries, and now we’ve got a bit of a mess.

That is also going to be part of the inventory process, trying to assess the places where permissions have been overwritten, whether it be for a legitimate reason or not.

Now as we think about where we’re going to move, some specific things that I’d like to bring to your attention and let you know about when it comes to the cloud. First up, when I say cloud, as I mentioned before, I mean Microsoft 365 or SharePoint Online. Two things that you want to be aware of if you’re assuming that you’re going to move all of your data haul hog into that environment, and that is there’s going to be some tangible costs in at least two forms.

The first of those is the cost of moving. Those of you that are used to taking a backup of your content database and attaching it to another server and you’re off and running, that might be in play when we’re on-premise but that’s not really an option when it comes to SharePoint Online. Now, Microsoft has hinted a bit that that might be an offering down the road, but for the day, if you’ve got 7 terabytes of data in your SharePoint farm and you’re going to move all of that online, then you’re going to be pumping that amount of data through the pipe.

Then as I hinted at before, once you get the data there, every byte that you’re using has a tangible cost. Again, the cost per byte might be really low but it’s a little bit different pricing model than it is back at your office. While the pay for what you use scenario does have some very nice points, you just got to be ever vigilant about this data that’s sitting there and not being used and not only do you have to think about that at your initial conversion, but you also have to continue to think about that down the road.

Finally, when it comes to customizations in the cloud, it’s a very restrictive story. Some of the things you’ve done in SharePoint Designer in the past may move to the cloud, some of them may not. However, any code-based customizations that you’ve written in the past in Visual Studio, they’re not going to move to the cloud. We’re going to have some hard decisions there to make about leaving them where they are, moving them to the cloud in the form of a rewrite or some other kind of choice.

Some other cloud things to think about, and I think some of these get overlooked in our zeal to embrace a new platform or a new way of doing things, and that is the physical ownership of data. First of those, privacy concerns. Really, the question you’ve got to ask yourself is, “Who is more trustworthy when it comes to securing your data?” I know that there is this natural human emotion that says, “Well it’s in our building so we have some level of security.” While that maybe true from a physical point of view, your building is set up like a fortress and it’s impenetrable, the reality is you really have to assess the skill and the expertise of your own IT team versus the IT team of whatever company you’re entrusting your data to.

I’m not trying to cast value judgments for or against your company or Microsoft or any other provider but it is a legitimate question that you need to ask yourself. As an example, I have an acquaintance that works at a power company. They have amazing security because they have a lot at stake. On the other hand, I have other friends that may work in more open environments where they’re really not secure or not sensitive I should say, to this kind of thing. You really need to think about that. Who do you trust more and try to make some accurate assessment of that.

The other thing to think about when it comes to the physical location of data is that there are actually some laws that come into play here. Certain kinds of data in certain countries are required under sovereignty or safe harbor laws to have that data stored physically within their national border and while that may seem kind of humorous given that it’s available electronically, there still are some legitimate reasons why this has to be enforced.

At the very least, you have to make sure if you’re going to the cloud that you’re not moving data into the cloud that can’t be there because it has to be physically located in a certain place. The way that a lot of companies are straddling this is by setting up a hybrid environment and the idea is that there are at least two things that would stay in your on-premise environment: sensitive data that has to be physically held there, near obsolete data that there’s no reason to move it to the cloud and then just get rid of it, and then we use the cloud really for growing new data.

Also something to think about on the hybrid is that if you have issues where you’ve got customizations that are not going to move to the cloud, the hybrid may be an option where you simply leave your customizations on-premise, let them run to the end of their useful life and then at some future point, replace them with something that’s cloud aware.

Let’s look at a few specifics now of the ThreeWill migration process and just introduce you to this, and again as a reminder, if you engage us, you’ll see these steps and many, many more, but even if you don’t, this just gives you an overview of what you ought to expect and the kinds of things that you ought to be doing.

I will point out that what I’m showing you here is definitely an overview. If I’m going to show you 20 bullet points, the actual plan that we use probably has 120 bullet points, so we’re really proud of the fact that it’s a very thorough process.

A few generalities about the process, first of all, it’s got a good track record. We’ve been using this thing for a long period of time, and as we’ve gone from version to version of SharePoint throughout the life of the company, we’ve constantly strived to improve this and  to keep it up to date with the latest tools and the latest techniques. Another thing that we think is a big value play in this is the fact that we also bring along a mature library of intellectual property artifacts: scripts, command line utilities, other things that will not only let us better assess the environment going in but also help us to assess success on the back side, to make sure that we accomplish what we set out to accomplish with the customer.

Another thing, we don’t really hitch our wagon to a particular set of migration tools. If the user wishes to purchase one, we have good flexibility in working with a lot of different ones and we’ll even provide some advice on that. On the other hand, if the user chooses not to make that expenditure, we have manual processes and scripts and other things that we can use to get the data moved.

I will say that we’re not really looking to endorse or talk about particular tools in this presentation. That’s something that will be left to an individual customer by customer basis, but if you’ve already spent the money on a tool and you feel like you need someone to come in and help you, just understand that we’re good with that and we can make it work.

All right, so those of you that do better with pictures as opposed to words, here’s your 30,000-foot flyby of how the process goes. The first step is simply an analysis of your environment and while we’ll break this down into greater detail, the biggest word that you would want to associate with this is inventory. Let’s figure out what we’ve got. Then from there, migration planning says, “We’ve got a good idea of what we’ve got. What are the steps that we’re going to do to get this done?”

Then customization planning, it’s a similar concept but now we’re talking about the workflows, the designer customizations, the code customizations that you have in an environment and this is where there’s really going to be a fork in the road about which things go forward and which things either have to stay where they are or go to a different environment. Then from there, we start practicing. If you’ve got a big game coming up, you’re not going to be good unless you go out and practice, and so really the dev/test migrations are just for developers and testers to be able to go to the iterative process of trying it out and seeing how close we’re getting and we would expect this very much to be an iterative process, where with each successive run, we get closer and closer to that ideal of a conversion. Again, the number of iterations is going to be in part driven by budget and time and other such concerns.

Then we actually do it. We’d pull the lever, we go through whatever steps we’ve planned to get the migration done. Then post-migration. Again, having the data land really is pretty far from the last step. As you’re going to see, there are a fair number of things we have to do in this post-migration process in order to make sure that we have a success.

Let’s break it down a little bit more then. As I mentioned a moment ago, the biggest thing we get from analysis is an inventory of all the SharePoint artifacts, and it’s funny, depending on your perspective, you may not even know some of these things exist. As an example, if you’re a manager in here, you may have no concept of a web application or a site collection or how many farms your company has, but from a technical point of view, it’s very important for us to assess every single thing that you have, and we’re lucky enough to have some tools in our toolbox that will allow us to do this. We have a good rich set of PowerShell scripts that will let us literally run through your entire installation and discover what we need to discover about what’s there and provide that in a consumable fashion.

I think you’ll also see that if you are using third-party tools, many of those also come with some analysis tools, and then not only do they have their own tools for doing analysis but if you are a company that is deciding whether or not to use a third-party tool, this is the place and the process where it would help you make that decision.

The other big thing that we’ve amassed over the years is a series of pre-migration checklists. We know these are the things that we’re going to have to know and have to get done in order to move through the process. Again, that’s part of what you get when you engage us is just our experience on what needs to be assessed, what needs to be checked off before we move into the next step.

What is the next step? It’s planning. It’s where we’re really going to try to get specific about how we’ll get this thing done. The first thing that we’re going to have to do is stand up one or more environments that we’ll use for our practice. We talked about the fact that we’re going to have to go through this several times to make sure we get it correct. A second step in that would be to obtain a backup of a production content database, and there is a certain amount of security that has to go around this one depending on the nature of your data.

As an example, if you’re using a SharePoint installation that holds health-related data, there might be some HIPPA concerns there. I know that I used to work at a company where we kept payroll information in our own systems and we had to be very careful about making copies of those for test purposes. Just consider that as you go through this step.

Then from there, we actually build a detailed migration plan. Every step we’re going to take, every place we’re going to invoke a tool and again, those of you that are used to traditional project management, this is really where you’re going to see all of the bullet points that you would go through and execute what we’re going to do. You’ll also have to consider in migration the idea of content cleanup, and I will admit even though I’ve been hard on the topic of cleanup and you really need to do this, that there is more than one place to do this. Sometimes, due to the nature of your environment, it makes more sense to clean things up on the front side while you’re in the planning process.

That could be particularly true in a case where you’re moving to the cloud and you don’t want to pay for bandwidth. On the other hand, depending on the sophistication of the tools that you’re using, it can also be that you migrate all of the data and it’s actually easier to sort it out on the back end. Again, this may be a pre or post migration step, but most likely it’s something that’s got to be done.

Now things to think about when it comes to customization. The biggest thing to consider is just do they even have an opportunity to move, and in a general sense outside of SharePoint, when you talk about migrating customizations, it’s either, “Hey, it will run exactly as it is or it has to go through some kind of conversion process or you’ve got to rewrite it from scratch.” I think what you will see is that when we talk about staying on premise, it’s going to be mostly as is, maybe a little conversion. When we talk about going to the cloud, it’s going to be a full rewrite.

We need to look at our workflows and in particular, we might want to consider any points where our workflow has been intertwined with some custom workflow activity that we either wrote ourselves or that we purchased from a third party. Again, workflows in a generic sense can transport on premise or online and there’s full backward compatibility support from the SharePoint 2010 workflow engine, but if we have some customizations working in there, we have to be aware of those.

Another big place that we have to look and this one gets somewhat overlooked, and that is the notion of user profiles. Are we holding data in our user profiles that we don’t really need to bring forward? If so, that might be an opportunity to call that information. Another big one that we have some specific experience with, if you go to a hybrid environment, there’s this whole thing about the user profile is now going to exist in two places and so there are some best practices and maybe even some code solutions that you might want to implement in that circumstance.

Then most companies nowadays are doing some kind of single sign on environment and so while the steps on this may vary, part of the migration is also being that we plan for this new SSO implementation so that people are able to log in to SharePoint in a seamless fashion without having to re-log in to that once they’ve already accessed the SSO environment.

It’s time to practice. At the beginning of our practice, we’ll get another backup of production. We’ll actually execute the steps we planned in the previous phase. If we have customizations, we’ll then implement those and then we’re going to test. We’re going to test as many things as we possibly can. Some of that testing may be automated. Most of it will probably be human based. Then from there, we’re just going to create a feedback loop. We’re going to identify and address the issues and then we’re going to repeat as needed and again, budget, accuracy, timelines, all of those things are going to affect how many times we do this.

I think when we go in to gauge on this, we have it in our mind that three iterations is a pretty good number but that may vary more or less, depending on your particular circumstances. Then once we actually get through the testing process, it’s game day. It’s time for us to really do it. First thing we’re going to do is get the production backup that we will actually act upon and then from there, we’ve got to stand down the production environment. The simplest way to do this is to simply go in and either do a redirection at the server or a redirection at the DNS level, that takes the user to a static migration in progress page if they attempt to access the production environment.

Then we execute the migration we’ve been practicing, implement customizations as we’ve been practicing, and then we do actually need to perform a test cycle to make sure that we repeated the results that we got in our test or dev environment, and then re-enable the production URL.

I hope I’ve made this point solidly but I’m going to make it one more time here. This is not the end of the migration. When the data lands and we pass our smoke tests, so to speak, we’ve still got a few things to do. Among the things that we need to do, if we didn’t do our content cleanup on the front end, we might want to consider it now. It may be a mix of the two. Maybe we cleaned up some data before we left and now that we’ve arrived, we’ve got some more to clean up.

Another thing that’s easy to overlook, we’ve got to think about updating our non-production SharePoint environments. Think about as an example, if you’re a company that does a lot of custom SharePoint environment, there are certainly developer desktop machines or laptops that are running SharePoint. We have to make sure that those environments are updated so that they mirror our production environment. Same thing with departmental servers that are used for testing purposes. They may need to be upgraded as well, so we’ve got to bring the whole company along once we make this move.

Whatever maintenance and support plans or agreements that we have on SharePoint, either with our internal IT or with external sources, those will have to be updated to take into effect that we’re in a new environment. We’ve go to update our governance plan and if I were to be brutally honest, what I’d have to say for some of us is that we have to create a governance plan, because maybe we’ve never really had one and this is the point in time where we’re going to step up and fix that problem.

Some other things that we want to do, however the environment looked before we migrated, we want to make sure we take a snapshot of that and hold it in case the very worst happens. Again, for a lot of us nowadays, given that we’re running on VMs, that may just be as simple as taking a snapshot of a virtual environment. On the other hand, if yours is running on physical hardware, it may be a matter of shutting the server down and simply cloning the hard drive. Either way, we probably want to hang on to that environment as it existed, just in case we discover some kind of fatal problem a few miles down the road.

Then finally, communication, communication, this can’t be undersold. Even if you do a perfect conversion, if your users show up on Monday morning and there’s a new alien environment and they know nothing about it, nothing good could come from that. Obviously, we’re going to have a lot of announcements along the way. We’re going to be very public about the schedule. We’re going to talk about a training plan and how things are getting done, so always keeping our customers in the loop about what we’re going to do is a really important part of this process.

We’re moving in to the latter part of the presentation here and we’re going to talk for just a moment about code-based customizations and what the world is going to look like going forward. Now as a developer, there’s this balance that we have. On the one hand, we love shiny new bubbles, but on the other hand, there is some baggage that always comes along with those, and that is certainly going to be the case here.

For SharePoint 2013, we have a completely new programming model and if you’ve not been on in any of the webinars that I’ve had on this or you’ve not seen about it from other sources, it’s not an exaggeration to say that it is a major change from what we’ve done in the past. The biggest change here is that we’ve been kicked off the server in a manner of speaking. We’re no longer allowed to write code that runs inside of the SharePoint server, so for those of you with a lot of experience, you’ll recognize that as the server object model that’s been taken away from us.

Then if that’s not where we’re going to program, where will we program? One place we can program is in the browser. It may be that a lot of things that you did server side in the past, you’re now actually going to manipulate those things from the browser. You’re going to use JavaScript and either some combination of the Microsoft provided client side object model or a REST cause.

Another place that you may write your code is on a Windows server that’s either available on the internet or available in your environment, or as an alternative, you may be writing some code that runs on Windows Azure. In either case, what you’re doing here is writing server code that’s going to be remotely communicating with and manipulating the SharePoint environment. Obviously, when we talk about writing in the Windows server environment, we think about .NET, although any supportive language for these environments could be used.

Another model, although it may seem obscure and a little weird is that we may be able to do this on other OS platforms. Again, given the fact that REST is a somewhat ubiquitous technology now, anything that’s capable of properly issuing and receiving REST calls and responses will be eligible to play in this party. Then those of you that are on the bandwagon of riding web-based apps or rich internet apps where you do almost all of your manipulation from the browser client, we have that kind of opportunity as well. It’s a big change and if you’re a more server-oriented programmer, I can just tell you, the world is changing and you’re going to have to change along with it. You’re going to have to begin to embrace writing code that runs in the browser, even though we may not do that exclusively.

Now in the past, the customization process in terms of deployment was a fairly laborious one, and it generally involved both developers and administrators to a pretty deep level. What we see in the new world now is a more streamlined model. Essentially, if you build customizations under this new programming model, there are two different ways that you’re going to get them out to the world. One way would be the App Store, and just as you think about an app store for your phone or your tablet or any other such things, this is really very similar to that.

Time will tell whether this is going to be a huge thing or not, whether people are going to get rich buying apps or building apps, I should say, whether companies are really going to buy apps from the app store, but either way, the process is in place. The infrastructure’s in place. Now something that immediately pops up if you’re an administrator, you see this concept of an app store and you think, “Boy, I’ve got some concerns about users that I don’t trust going there and buying things.” The good news for you is that your environment is fully controlled as to whether or not users can use things from the app store and in fact, there’s even a model where if you shut down that capability, a user can go to the app store, look at an app and then actually file a formal request for that. You’ll be able to see that request and then make some kind of value judgment about whether you want to permit that app within your company or not.

I think it strikes a really good balance between letting the users have some self determination and whether the administrators have the control that they need. Now a little closer to home, you also have this concept of an app catalog. There’s really two ways that you can think of the app catalog. In some respects, it’s almost like an internal version of the store where you put approved apps that have either been purchased from the app store proper or that had been built within your company or built by third parties.

Maybe another way to think about the app catalog, for those of you that are more technical in nature, it really is just a specialized site that holds all of the apps that we’re going to use within our company, and then those apps are made available to our users and they can consume them as they see fit. Thinking about all the hoops we’ve had to jump through in the past to get things deployed, I do think that’s a pretty nice step here in that there’s a lot less baggage and a lot less entanglement when it comes to deploying something.

One little asterisk that I do have to put on this page and you want to think about it, if you write an app that involves some kind of server code, we’ve already said that that code is going to run somewhere else on some other server. Just understand as you go through this process that in some cases, there maybe dependencies on other network servers, either on our local network or in the cloud.

What programming model are you going to choose? The good news if you’re on premise is that you have a lot of options. SharePoint 2013 still has backward compatibility with the SharePoint 2010 solution architecture. If you’re used too using Visual Studio and you’re building solutions and using the server side object model and creating farm solutions and features and all those things, when you’re on premise, that’s always still on the table even though you’ve moved to 2013.

In fact, for those that are going to implement hybrid environments, I think this is a huge driver because it’s really easy to see a model where you say, “We’re going to move new stuff to the cloud and then we’re going to keep an on-premise server as well so that we can run our code to the end of its useful life and then give it a proper retirement.”

In addition to that, even if you stay on premise, you do have full support for the new app model as well, so over time, as you begin to update or rewrite things, you can go ahead and write them with this new model even though they may still be running with interim environments, and then overtime, we have the ability to move those up to the cloud as we see fit.

Not a lot of you used Sandboxed Solutions. They weren’t widely adopted but if you are in that small audience that chose to use those, there’s good news and bad news. The good news is that they are still fully functional and they will run in this new environment. The bad news I should say is that Microsoft has associated the word deprecated with these, so they won’t say they’re unsupported. They won’t say they’re crippled because neither of those things are true, but by applying this label deprecated, what they’re really saying is, “Yeah, we’re walking away from these.”

Another case where if you’ve got the code investment, you can continue to run it in the current environment, but probably a signal that as you think about new development, you don’t want to be using Sandboxed Solutions. You want to begin to move away from those.

Now the story is different in the cloud, as I’ve already hinted at. You only have one programming model in the cloud and that is the new 2013 app model. There’s no support for sever object model, farm solutions, no putting anything in the 15 hive. No, those kinds of things are going to be permitted here. There is deprecated support for Sandboxed Solutions here as well, although it has been our experience in some of the proof of concepts and prototypes that we’ve written that even Sandboxed Solutions are supported in a cloud environment. They do have what I would call some undocumented or vaguely documented limitations, particularly around the areas of event handling, so just buyer beware if you can try to do that.

Let’s recap what we’ve talked about and then I’ll pause for a moment to see if there are any questions. If you went into this with a naïve idea about migrations being a simple proposition, then I hope maybe we’ve helped you understand that there is a bit more to it. That’s particularly true for those that might be signing the checks in the business owner community or the users that are going to be writing through this process.

Having a good plan for your testing and your execution can really help a lot and we feel like that we bring a very tangible strength there. The use of tools, again somebody selling you a tool, that doesn’t necessarily mean it’s good or bad. You really want to do a good assessment of the appropriateness of that tool for your environment, and that’s something we can help you with as well. Then again experience. That’s the big thing that we feel like we bring to this process and we’d be eager to help you with your migrations if you find yourself in that circumstance.

I know anytime I reach the end of a webinar, some people are going to sprint away as quick as possible because they’ve got other things to do. Let me just recap real quickly again. I appreciate your time. Anytime you take time out of your day to listen, I know there’s a tangible cost in that and so I hope it’s been helpful. Again, you see my contact information on the screen. If you missed anything or if you want to dig a little deeper, I would encourage you to take advantage of that. Also, we always take these and we do record them and put them up on our video channel up on Vimeo so if you’d like to see a replay of this. Generally, what we do is we update the blog associated with each one of our events to point to the video link. If all else fails, you should able to go to threewill.com and check out our blogs and find an updated link to the video.

That’s it for my prepared presentation. I’ll hang around for a moment to see if there are any questions, and for those of you that are departing immediately, thanks for joining us and have a good day.

Share and Enjoy !

Related Content: