One of the most common reasons Domino upgrades become complicated is insufficient preparation.

Not because the upgrade itself is inherently difficult — but because environments that haven’t been reviewed for some time often contain surprises. Undocumented applications, unsupported operating systems, forgotten integrations.

The good news is that most of these issues are straightforward to address when identified early.

This guide covers the key areas to review before starting a Domino upgrade, and why each one matters.

1. Know What You’re Running

The starting point for any Domino upgrade is a clear picture of the current environment. This means confirming:

• Current Domino server version across all servers
• Number of servers and their roles (mail, application, hub, etc.)
• Server operating system versions and support status
• Physical or virtual infrastructure
• Geographic distribution (single site or multiple locations)

This sounds straightforward, but in environments that haven’t been formally reviewed for several years, the reality is often more complex than expected. Shadow servers, test environments that became production, and servers running on end-of-life operating systems are all common findings.

Getting a clean inventory first removes uncertainty from everything that follows.

2. Understand Your Application Landscape

For many organisations, this is the area that requires the most attention.

Domino environments frequently contain:

• Business critical applications built specifically for the organisation
• Databases that have accumulated over many years
• Applications whose original developers are no longer available
• Workflow and approval systems deeply embedded in business processes

Before upgrading, it is important to understand which applications are actively used, which are dormant, and which are genuinely critical to business operations.

This is not about replacing or removing applications, it is about understanding dependencies so the upgrade can be planned around them rather than discovering them during it.

3. Map Your Integrations

Domino environments rarely operate in isolation.

Common integrations to review include:

• SMTP relay and mail routing configuration
• Directory integration (Active Directory, LDAP)
• Third-party applications connecting to Domino data
• Traveler and mobile device management
• Nomad Web deployments
• API connections and web services
• TLS certificates and authentication configurations

Integrations are one of the most frequent sources of post upgrade issues, not because they break easily, but because they are often underdocumented and only noticed when something stops working.

A pre-upgrade integration review is one of the highest value activities in the planning phase.

4. Review Your Notes Client Deployment

If your organisation still uses the Notes client, the client rollout is often the most logistically complex part of an upgrade.

Key questions to answer before starting:

• How many Notes clients are deployed?
• What versions are currently in use?
• How are clients currently deployed and updated?
• Are there any custom client configurations or templates?
• What operating systems are clients running on?

Understanding the client estate early allows the rollout to be planned properly — whether that means a managed push, a phased department rollout, or a pilot group approach.

5. Confirm Your Licensing Position

Licensing is an area that is frequently overlooked in upgrade planning and occasionally causes delays.

Before starting, it is worth confirming:

• Whether servers and users are covered under active HCL support or subscription
• Whether licence counts reflect the current user base
• Whether any licence reinstatement is required before upgrading

For organisations under active HCL subscription, upgrade rights are typically included. For those who have allowed support to lapse, reinstatement may be required before proceeding.

Confirming this early avoids surprises at the point of upgrade.

6. Plan Your Backup and Rollback Position

A structured upgrade always includes a clear backup and rollback plan.

This typically means:

• Full server backups completed immediately before upgrade
• A documented rollback procedure in case of unexpected issues
• Agreed rollback decision criteria (what would trigger a rollback)
• Out-of-hours upgrade windows for production servers where possible

In practice, rollbacks on in family Domino upgrades are rare. But having a clear plan in place means the upgrade can proceed with confidence rather than caution.

7. Use a Test Environment

Upgrading a test environment before touching production is one of the most effective ways to reduce upgrade risk.

A test environment allows:

• Validation of the upgrade process before it matters
• Testing of business-critical applications post-upgrade
• Integration testing
• Identification of any compatibility issues in a safe setting

For organisations without an existing test environment, a temporary clone of the production configuration is usually sufficient.

The time invested in test environment preparation is almost always recovered during the production upgrade.