Approaches and Practices for Sitecore Maintenance Projects

Approaches and Practices for Sitecore Maintenance Projects


Rodrigo Peplau, Solution Architect & Sitecore MVP

Leonardo Cunha, Sitecore Developer

José Neto, Sitecore Developer

Nonlinear Digital |

This article can be download it at:


Producing a piece of software poses multiple challenges. Sitecore, for example, is a web platform built for capitalizing on highly targeted and personalized digital marketing opportunities, but the added complexity means that Sitecore maintenance teams must deal with a specific set of challenges involving topics relating to: recursivity, search indexes, logged areas with multiple providers, mailings, social connectors, security and permissions, improving upon the content editor and user experiences, and more. This added complexity is the reason why having an experienced Sitecore maintenance team is so crucial to the ongoing success of a Sitecore site.
High-quality Sitecore project maintenance work differs from normal development in several ways.  

How maintenance projects differ from normal web projects

Legacy code – The team tasked with a maintenance project is often not the same one that developed the original Sitecore project. Dealing with legacy code can be challenging for a maintenance team, especially when the two teams work for different companies or the people who built the software are not readily available for consultation;

More complex problems – When a company schedules the go-live date of a new website, they often invest dollars into its promotion. If they’re not absolutely critical, tackling harder, more complex problems can be postponed so the launch date is not compromised. After the go-live date, when the responsibility shifts to the maintenance team however, they are no more excuses: it’s time to tackle those difficult, lingering issues. The resulting solutions won’t be found on first page of a Google search results page;

Urgent issues – When a live website isn’t behaving as it should the maintenance team must act fast. Maintenance teams need to constantly work under pressure, dealing with concerned people while delivering results;

Faster results expected – When a project is in development, it is normal for the design, production and testing process to take months. Development teams can afford to spend weeks per iteration. When a maintenance team is in charge however, contracts are usually smaller, so results must be shown much faster;

Harder to control – It is easier to lose control of budget and dates when dealing with smaller contracts, as is the case with maintenance work. In the blink of an eye, days can be wasted. A more efficient, optimized process must be put in place, as managers have very little time to spend monitoring these activities;

Importance of Team Seniority – In order to ensure team efficiency and minimize time spent monitoring, it’s important to work with a senior maintenance team — otherwise they’ll be less adept at:

  • Producing better quality software, which takes less time to pass Quality Assurance and requires less reworking;
  • Efficiently communicating with clients, which would demand less time from a Project Manager;
  • Independently solving problems, being resourceful, and knowing how to ask for help;

Contract Types

There are usually two types of maintenance agreements that can be made:

TYPE 1 – Development or Change – Stakeholders want to expand the project somehow such as by creating new modules and pages, or they want to modify the way existing things work.

TYPE 2 – Support – The project is live and needs experienced hands to ensure it continues to stay up and running. This type of maintenance agreement focuses on eliminating new or existing issues that can appear on the live site as well as expanding the current site to include new features.

Maintenance Work at Each Phase of Development

The challenges and particularities of a maintenance project all impact the way it’s executed at each stage. Here are some highlights:

Requirements – Business-level requirements are usually less complex than those accompanying non maintenance projects, however they tend to be communicated more chaotically and thus become harder to manage. It’s crucial to pay attention to requirement details in order to effectively assess potential implications and validate everything before beginning the project. Remember: time is short, steps must be taken to avoid the need to re-work any element of the project. To further complicate matters, most requirements gathering practices (e.g. focus groups, interviews, prototyping, workshops, etc.) are harder to execute due to time and budget constraints;

Planning – Estimates and planning takes place based on the requirements gathered. Writing leaner plans that allow little room for changes is often necessary. Using resources efficiently cannot be emphasized enough. As support contracts normally have a set number of hours per month and issues are solved as they arise, planning must be periodically revisited;

Execution – It’s important to demonstrate the work in progress, whether by publishing somewhere stakeholders can easily browse and view it, or by doing demos and screen sharing. If anything needs to be adjusted, it must be identified as soon as possible;

Quality Assurance – Time spent testing must be kept to a minimum, however this crucial step must be observed to ensure the overall quality of the project. Although code written by a senior maintenance team will need less testing, the QA analyst must still work efficiently to meet timelines.

Deployments – One of the Achilles’ heels of any maintenance project is that deployments take place much more frequently than during a regular web project. During a normal project, deployments are usually only executed at the go-live stage, however subsequent maintenance projects necessitate frequent updates to the live servers which increases the chance of something going wrong. To minimize issues as much as possible, it’s important to establish processes and conventions for deployments.

Maintenance Environments

While a maintenance project is active, the maintenance team will need access to environments where their activities will be executed. The website(s) are hosted on live servers and the maintenance team will most likely need access to the source control. During the development process, developers will map to source repositories as well as build and deploy on their machines. In addition to that, other servers can be dedicated to specific tasks (as shown below). (It’s worthwhile to note that these practices are beneficial to have in place for web projects beyond the next maintenance project.):

Health Check Environment – This environment is where the work in progress can be placed in order to ensure nothing is broken. Automatic builds can be set up to be triggered every time something new is at the source control.

Quality Assurance Environments – QA tests are executed on this server, so update time frames need to be planned and communicated in order to ensure QA tests aren’t interrupted. It is important for restoring this server to be easy, as tests can often break it.

User Acceptance Test Environments – These environments are open to the public. This server can be prepared and used to run demos for clients, allowing them to interact with things you’ve produced. This must also be easy to restore, for the same reason as the Quality Assurance Environments.

Solution Knowledge Transfer

In order to successfully shift the project to the maintenance team, it’s necessary to somehow conduct a project knowledge transfer. This knowledge transfer consists of a collaborative process that involves the client’s team (their project managers, developers, and analysts) sharing all relevant information regarding that specific project with the maintenance team.
The client will be asked to share information spanning three categories:

  • Infrastructure: Servers names, IP addresses, VPN Credentials, Databases, etc.
  • Architecture: Integrations with others software, additional third party modules used in the software, etc.
  • Product: Usability, flows, notifications, workflows, etc.

This process is crucial as it greatly helps to reduce the learning curve of the Maintenance Team.
Ticket Control
During the maintenance process, the client usually opens a request using a Ticket System (such as JIRA).

This system helps foster better organization and communication between the client and maintenance team. The requests can be separated into categories such as:

There are also helpful statuses on the tickets that enable the teams to keep track of the requests. JIRA tracks the tickets’ statuses:

  • Open: The ticket opened on the system
  • Assigned to: The ticket is assigned to a specific team member for evaluation
  • In Development: The ticket requires development effort and this work has begun
  • Waiting for Customer: The maintenance team member is waiting for feedback or an answer from the client.

Regular Meetings

Good communication throughout the execution of the project is very important. Without proper communication, it is easy for the project to get off track, resulting in unnecessary pressure on the team. Periodic meeting are recommended for the team to discuss the overall progress, review the tickets and solve possible doubts regarding them.


It is also essential to have periodic internal team reports to share the number of hours spent to date. A weekly email, for instance, can be sent to inform team members how many hours were spent and which tickets have been tackled during that time.
The Nonlinear Digital team also emphasizes the importance of scheduling client meetings in order to align project priorities with stakeholders and to provide transparent reports about the latest deployments. This process ensures everyone will have full knowledge about the work status of any given maintenance deployment project.

 Implementing a Solid, Regular and Consistent Deployment Process

 Deployments frequently take place during maintenance projects. The primary goal of a reliable deployment process is to eliminate the chance of any surprises. A maintenance team will minimize risks by performing small regular deployments rather than performing a large deployment every six months. Of course, this period can vary according to the context. In addition, deploying bunches of features in small packages helps to decrease the chance of unpleasant surprises.
In addition to these practices, the Nonlinear Digital maintenance process provides: 

A more careful process at Source Control

The maintenance team maintains distinct branches to support quick and short changes as well as larger ones that are to be deployed in the long term, if necessary. Each isolated branch serves a different purpose. The maintenance team allocates one specific “release” branch where only the changes that are ready to be deployed can be merged. It is easier and more efficient to identify the changes and therefore the files that need to go live.

Deployments to environments with direct access or via helpdesk

When the maintenance team has full access to live servers, deployment is easier. It’s important to follow good back up and deployment practices, so everything can be rolled back easily if something goes wrong. Every deployment has to be fully organized in a way that makes it easy to track and revert, if necessary. Some host providers, however, won’t allow direct access to their servers. In these cases such as these, a maintenance help-desk would be responsible for doing the hands-on work based on written ticket requests. It is very important for the client to spend time writing clear and detailed requests, in order to ensure that the help-desk fully understands what needs to be done and can successfully accomplish the request. Once again, communication is key.

Deployments under stakeholder’s approval only

As previously described, User Acceptance Test environments are meant to be used as a place for validating everything before the deployments take place. Deployments should only be executed after everything has been both fully client-tested and approved.
Deployments must also take place at scheduled dates and times, so that any running activities are not interrupted.

In summary, this overview of Sitecore maintenance practices and approaches should provide an outline of the purpose and unique nature of maintenance projects, as well as the expectations Sitecore clients should have of their maintenance team.

We’re dedicated to your website
Throughout the entirety of your partnership with Nonlinear, a minimum of one Nonlinear Sitecore developer will maintain an intimate understanding of your website’s unique build, meaning you’ll benefit from a faster response time with maintenance requests. Nonlinear maintains a fully staffed team for all of the ongoing support and maintenance of our clients.

We’re flexible
Be as involved as you would like to be. We can partner with your existing, internal development team or you can choose to outsource all technical and marketing activities to the Nonlinear team.

We’re a leading Sitecore partner
The Nonlinear team has a deep, technical understanding of the Sitecore product architecture and of the development best practices required to ensure efficient and stable operation.

Leave a Comment

%d bloggers like this: