Database Instances
Manage SQL Server, Oracle, MySQL, and PostgreSQL database instances as first-class CMDB entities. Database Instances sit between the host device and the individual databases — giving you visibility into the engine layer that is often missing from traditional CMDBs.
Overview
A Database Instance represents a running instance of a database engine (e.g. a SQL Server named instance, an Oracle SID, or a PostgreSQL cluster). It captures engine version, edition, port, and authentication type — information that is critical for migration planning but not typically stored at the device or database level.
Database Instances are accessible from the CMDB area and appear as a dedicated tab alongside Devices, Applications, Databases, Hosts, and Networks.
Relationship to Devices & Databases
The CMDB hierarchy for database assets is:
Device (the host server) → Database Instance (the engine) → Database (the individual database)
A single device can host multiple database instances (e.g. a server running both SQL Server 2019 and SQL Server 2022 side by side). Each instance can contain multiple databases. This three-level hierarchy gives you precise control when planning migrations — you may need to migrate instances independently even if they share a host.
Key Fields
| Field | Description |
|---|---|
| Instance Name | The name of the database instance (e.g. MSSQLSERVER, SQLEXPRESS, ORCL). |
| Engine Type | The database engine — SQL Server, Oracle, MySQL, PostgreSQL, etc. |
| Version | Engine version number (e.g. 15.0.4316.3 for SQL Server 2019). |
| Edition | Engine edition — Standard, Enterprise, Express, Developer, etc. |
| Port | The TCP port the instance listens on (e.g. 1433, 1521, 5432). |
| Host Device | The CMDB device record that hosts this instance. |
| Authentication Type | Windows Authentication, SQL Authentication, Mixed Mode, etc. |
Managing Database Instances
Open Discovery → CMDB and select the Database Instances tab.
Click New to create a record, or select an existing instance to edit. Populate the engine type, version, edition, and host device fields.
Existing database records can be associated with the instance via the host device relationship. This completes the Device → Instance → Database chain.
Migration Planning Considerations
Database instances require careful planning beyond simply migrating the host VM. The instance layer introduces dependencies, compatibility requirements, and licensing considerations that must be resolved before cutover.
| Consideration | Details |
|---|---|
| Engine Version Compatibility | The target environment must support the same engine version, or a tested upgrade path must be planned. SQL Server 2008 R2 instances, for example, cannot be restored directly to SQL Server 2022 without intermediate steps. |
| Edition Licensing | Enterprise Edition instances require Enterprise Edition licensing on the target. Confirm target licensing availability before wave planning — downgrading editions to cut costs requires application testing. |
| Named Instances vs Default Instances | Applications connecting to a named instance (e.g. SERVER\SQLEXPRESS) will fail if the instance name changes on the target. Plan to preserve instance names or update all connection strings before cutover. |
| Port Changes | Non-standard ports require firewall rule updates on the target. Record all non-1433 ports in the CMDB so network teams can prepare target firewall rules in advance. |
| Authentication Mode | Instances using SQL Authentication may require credential updates post-migration. Windows Authentication instances depend on domain connectivity — validate domain trust relationships to the target environment. |
| Linked Servers & Cross-Instance Dependencies | Instances that have linked server connections to other instances must be migrated in a coordinated sequence. Use the CMDB Application relationships to map these dependencies before assigning instances to move groups. |
Data Quality
Database Instance records are a frequent source of data quality gaps — engine versions, editions, and port numbers are often unknown or undocumented at project start. Use the following approach to improve data quality.
Request an export of all database instances from your DBA team (typically available from SQL Server Central Management Servers, Redgate SQL Monitor, or a manual audit). Import via CSV to bulk-populate instance records.
Ensure every Database Instance record has a Host Device populated. Unlinked instances won't appear in capacity planning or move group assignment views.
Use the Data Quality dashboard under Discovery → Data Quality to identify Database Instance records missing Version or Edition. These are the fields most critical for migration planning.
Tips
- Populate engine version and edition. These fields drive migration readiness assessments — knowing whether an instance is Enterprise or Standard Edition affects licensing and target sizing.
- Use CSV Import for bulk population. If you have a spreadsheet of database instances from a DBA team, use the CSV Import wizard to bulk-load them into the CMDB.
- Check port numbers for firewall planning. Non-standard ports are common for database instances. Recording them in the CMDB ensures firewall rules are correctly planned for the target environment.
- Treat instances as migration units, not just hosts. When assigning devices to move groups, check whether any device hosts multiple instances that have inter-dependencies. Migrating them in separate waves can cause connectivity failures.
- Flag end-of-life instances early. SQL Server 2012 and older, or Oracle versions past extended support, should be flagged in the CMDB for upgrade-during-migration treatment. These can't simply be lifted-and-shifted without an upgrade plan.