Since the publication of this article, ShareGate Desktop has updated and unified the migration interface. The following screenshots may no longer be accurate, we are working on updating them.
Development and deployment lifecycle can be part of the governance plan. We like to add it specifically if our customers don’t have a strong process to regulate new features, SharePoint information architecture evolution, but also new sites or new workflows.
Deployment usually includes custom code, xml, and interface design code, but it can also be to deploy SharePoint On-Premises or Online out-of-the box improvements. Such improvements could be creating a new content type, adding new columns to lists, publishing new workflows, new forms, merging two sites into one, or promoting a site as a site collection.
The common mistake is to make these improvements directly into the production environment. It might be alright to give users design rights if you have an open governance. But for sites like websites or intranets, a simple new column addition must follow a deployment lifecycle process if you don’t want unwelcome surprises and have to scrap your production.
Sharegate is a day-to-day SharePoint management tool helping you migrate, build your security and explore reporting reports. It’s not known as a deployment tool but it can surely help you a lot for that!
Deploy SharePoint Solutions: The Best Practices
Application development lifecycle might be complicated sometimes, but this is a process you must implement before starting a new project. We always advise our clients to implement the following production process.
We like to start with the developer environment, where new code or new features are developed. When the development team completes their task, the feature is pushed to integration. The main goal here, especially if you have multiple teams, being to verify that new code is integrated and avoiding any negative impact on the existing application.
When the deployment package is ready, the system administrator and development team collaborate to deploy onto the Quality environment. This is where end-users test the new feature and run acceptance tests. When it's ready to hit production, the system administrator and development team collaborate once again to deploy on the pre-prod environment, which has to be the same as the production one.
Once everything is ok, the new feature can be deployed and used on the production environment.
The process might change for your company depending on whether you have a development team inside your organization or if you work with a service company for the development expertise.
There’s one rule you can never transgress though: Always go from development to production, never the reverse!
Two Common Mistakes during the Deployment Process
Data from Quality Environments Are Not Transferred to Production
"We don’t want to redo the work already done"
I think this is the most common comment we have from clients when they want to deploy SharePoint solutions. When testing features on the quality environment, we ask them to test the feature as they would use it in production.
Sometimes, it ends up being a complete intranet, with lists and libraries, and items and documents, lots of metadata as well. Be clear with your quality testers, this is not the end product and everything done inside is going to be lost.
If your new features are deployed only with scripts and executables, you cannot keep the data. Make sure end-users are aware of that.
Pre-Prod Environment Is Not the Same as Production
Ensuring that pre-production and production are exactly the same is potentially the most difficult part for an administrator. First, the structure is not the same. SharePoint is a platform where end-users can do a lot: it’s easy to add a sub-site, to create a new column or a content type directly in production. Custom additions can be a pain when it’s time to deploy new features. Plus, there’s the risk you might erase what end-users have done.
On the other hand, SharePoint content progresses every day, new documents are added, new items on lists, new images … New content can impact your SharePoint's behavior, especially if there are running workflows, lookups, and so on.
Sharegate Is Your Deployment Tool
Ensure Your Test & Production Environments Are the Same
Copying a complete site collection with its content and subsites is the best way to ensuring your source and destination are the same. Mapping options can help when it’s time to map permission levels, users and groups, or site templates.
Get the Same Architecture Everywhere
The copy object feature is more granular than you think. The right panel allows you to choose to migrate only a list or a library, content types, Site columns, Users, Groups, Permissions Levels, Workflows, Nintex Workflows, and Managed metadata.
This feature is really useful when you improve the information architecture (add a column to an existing list) and need to keep the content for production. It's very convenient because you can avoid a big deployment with scripts and long procedures for a single new column!
Plus, Sharegate will automatically copy dependencies to make sure your migration is complete. For example, when moving a new content type, all new columns will be also copied.
For each object copy, more options are available. The most common options are to keep the content, copy the workflows, and copy everything that can be linked to the object!
Copy Object without Its Content
When copying an object, you can choose to keep the content from the source. At the beginning of the post, we said that content and data is never preserved from quality to production, this is where Sharegate comes very useful!
Only Copy the Content That Has Changed
Don’t tell my coworkers about this one! If for some really important reason you have to keep data from source to destination (and also preserve the actual production data), you can use the incremental copy, which you can find with the Copy Content Feature. Only newer versions of documents are getting copied.
Information Architecture Improvement
SharePoint collaboration, intranet and team sites change with time. You might need to merge two sites into one, move a list to another site. Or, just replicate the structure of a site without the content for a new site. You can also promote a site to a site collection to your destination (On-Premises and Office 365).
What are your worst headaches when you deploy SharePoint solutions? How do you find Sharegate helpful?