Know the true scope of your project from the start

In the earlier parts of this series, we talked about how to focus the project scope on what’s most important and how having an overview of your code base can help you be more efficient and make better decisions for your project.

In part 3, we want to take on one of the big hurdles most of us know very well from personal and work related experience: “Finding a good place to start”.

It doesn’t matter if your Notes/Domino project is modernizing your infrastructure, migrating to the Cloud or leaving the platform entirely. Consolidating your existing infrastructure is a crucial first step in the most successful projects. Finding and removing the deadwood in your environment will significantly reduce the overall project effort and save costs.

Please accept marketing cookies to view this video.

Ask the questions that reveal the core of your project

Asking the right questions was a key factor in reducing the project scope in the first part of this series. Let’s take a look at some of those questions again and concentrate on how we can use the answers to identify consolidation potential.

1. What’s the structure and size of my environment?

You must have a true understanding of the magnitude of the undertaking.  You need KPIs to help evaluate consolidation potential and measure success:


  • How many users are registered vs active?
  • When were the users last active?
  • How many applications do my users really work with?


  • How many servers are active?
  • How many are application servers?
  • How many databases are being used on a server?
  • How many users are active on a server?


  • How many applications are deployed vs used?
  • How many DBs can be excluded from my project?
  • How many databases are based on standard templates?
  • How many replicas of each database exist?
  • How many users are active per database?

2. How many databases are unused?

This is one of the most frequently asked questions we hear. It’s an obvious starting point for consolidation.

The first instinct is often to simply remove all unused database instances and celebrate a quick win. That can make sense in some situations: e.g. – when one is only looking to reduce the number of servers, but it is very unreliable for judging which applications can be de-commissioned.

More interesting is to find out for how many applications no database instance is used. These groups of database instances which share the same Replica ID are what we call “Replica Sets”. Only if the entire replica set is unused and activity does not occur on any server, can an application truly be considered unused.

The period over which activity is observed plays an important role in decommissioning. Not every database is used every day. You might have databases with seasonal usage which are only used once a year, quarter or month. To capture this variation, panagenda recommends a minimum observation period of three months to ensure a database is unused. The longer the observation period, the better decisions you will be able to make.

Having identified the deadwood, we take the first step to cleaning our environment, we continue to seek opportunities in slightly more demanding areas.

3. Where can costs be reduced?

A consolidation is an opportunity to find and eliminate the cost of unused licenses. Most organizations carry inactive users and under-utilized servers on their books. Acting on this information can save a lot of money with very little effort.

Finding and eliminating inactive DBs from your environment results in decreased server utilization. Consolidating several under-utilized servers reduces license, operations and administration costs.

The consolidation is also an opportunity to review the design of your Domino network. For example, environments designed 15 years ago with bandwidth considerations in mind should be re-evaluated. Modern infrastructure might have already made previously important redundancies or parts of the server de-centralization concept obsolete.

Many organizations choose to create hybrid environments with applications running on multiple solutions. Even if Domino remains a strategic application platform, certain generic services (e.g. mail, team rooms or file libraries) might become de-coupled from it over time. In such a migration scenario, user activity is also affected. Additional license savings potential is generated and can be predicted by understanding database design.

Even if you are not currently engaged in a particular project, the fast pace of change in dynamic working environments creates constant opportunities to reduce overall IT spend through continuous activity reviews.

Find the low-hanging fruit – standard template-based applications

The concept of design inheritance will be an important topic throughout your project journey. The second part of this series introduced us to the general topic and the impact it has on the growth of Notes/Domino environments. Design in general is of great significance during migration and modernization projects. Its importance may start as early as the consolidation phase.

Identifying databases that inherit design from standard templates is important for a couple of different reasons. From an organizational perspective, it’s comparatively easy to understand the purpose they serve, even without knowing the business process they are involved in. For example, a document library will be used for exchanging files, archiving documents or something along those lines. No matter if they are used in departments Procurement, Controlling or Manufacturing. Getting that level of insight into custom developed applications can be quite a challenge if those applications have been evolving over years. This is especially true if you are not just looking at one or two, but hundreds or thousands.

From a technical perspective, it’s immensely valuable to know what technical features such standard databases provide. It will provide a perspective on whether it’s feasible to use them via the web or make them available on mobile devices. Especially since HCL is investing a lot in modernizing classic templates, that might be a huge gain in a modernization project. In migration it can also be very profitable, because for most of the standard templates, there are ISVs who offer standard migration paths to other platforms. They can almost be excluded from the scope of manual migration work which in turn influences various KPIs like “users active” or “DBs used on server”. Whatever the path, working with standard template-based applications will be way less expensive than transforming custom developed applications.

Now, reap the rewards

Let’s combine those topics and apply them to your consolidation project to sum up how you can best benefit from the findings. We can even create a small checklist  to use as a step-by-step guide through the most important things to consider:

Task: identify unused applications

  • Impact: prepare reduction of server utilization
  • Impact: reduce project scope

Task: identify applications based on standard templates

  • Impact: minimize migration/modernization effort
  • Impact: discover user license cost reduction potential

Task: identify inactive users

  • Impact: discover user license overspending
  • Impact: prepare reduction of server utilization

Task: identify under-utilized servers

  • Impact: discover server license cost reduction potential

Task: review Domino network design

  • Impact: discover server license cost reduction potential

Next in our series

After that initial consolidation phase, once everything is trimmed down, the low-hanging fruit are picked and the license cost savings potential is clear, we take on the tasks that are more time and resource intensive. Here, the difference between modernization and migration projects will become more pronounced. However, it will also be a time to verify the calculations behind your business case. If you want to know more, this topic will be discussed in the last blog post and webinar of this series.

No matter what your project is though, there are a few strategic pieces of information you will always need. We will be covering two of the most important topics in our upcoming blog posts and webinars:

The ability to identify application stakeholders is of crucial importance when trying to decide on the future of an application. We need the departments or people who use the application to understand its role in the business process. However, we also need to know which departments or locations use it to be able to distribute the cost of our modernization or migration effort.

Most of your applications will have dependencies on one part of your environment or the other. Many of those will be rooted in the code itself: hard-coded server or usernames, IP addresses, external libraries, fax systems, etc. We need to know where these dependencies are, what impact they have and how they can be fixed in the most efficient manner, without having to re-engineer hundreds or thousands of designs.

From here on out it will be a continuous widening of the circle of applications we are working on. Each step will be more cost intensive, and prudent planning will yield ever greater benefits.

About this series:

Many companies around the world have been committed to HCL Notes/Domino* for years. They know the many benefits that come from that relationship. Additionally, Notes/Domino lies at the center of their processes and how they work. Despite all this, IT decisions makers around the world are starting to envision a future where Notes/Domino may play a reduced role or no role at all.

*formerly IBM Notes/Domino