Databases
The Databases module tracks all database instances across your migration scope — from SQL Server and Oracle to MySQL, PostgreSQL, and MongoDB. Accurate database records, linked to their hosting servers and dependent applications, are essential for safe sequencing and RTO/RPO planning.
Overview
Databases represent some of the highest-risk assets in any migration. They are stateful, often shared by multiple applications, and carry strict data integrity and availability requirements. The Databases module gives your team visibility over every instance in scope, along with the critical planning parameters — size, backup schedule, RTO, and RPO — needed to make sequencing decisions.
Each database record links to the device (server) that hosts it and the applications that depend on it. These relationships feed the dependency graph, allowing Clarity Migrate to warn you when a database and its dependent application are assigned to different migration waves — a scenario that would break the application when the server is migrated.
The Databases module supports all major platforms: SQL Server, Oracle, MySQL, PostgreSQL, MongoDB, and others. The Type field enables platform-specific filtering, which is useful when planning tool selection and DBA resource allocation.
When to use this
- Initial inventory: Register all database instances at project kick-off, especially before capacity planning begins.
- RTO/RPO planning: Record Recovery Time and Recovery Point Objectives for each database to inform backup strategy and migration window sizing.
- Dependency mapping: Link databases to their hosting servers and consuming applications to ensure co-migration logic is accurate.
- Capacity planning: Database size data feeds the storage requirements calculation for target infrastructure.
- DBA task assignment: Use the Owner field to assign databases to specific DBAs for pre- and post-migration validation tasks.
- Backup verification: Record backup schedules so DBAs can confirm backups are complete before migration windows open.
Key features
Step-by-step instructions
Adding a new database
Fill in the following fields:
- Name — the database instance name (e.g.,
SQLPROD01) - Type — the database platform (SQL Server, Oracle, MySQL, etc.)
- Instance Name — the SQL/Oracle instance identifier if applicable
- Size (GB) — current database size
Linking a database to its hosting server
Linking a database to consuming applications
Bulk editing and exporting databases
Important fields
| Field | Required / Optional | Description |
|---|---|---|
| Name | Required | The database instance name or identifier (e.g., SQLPROD01\MSSQLSERVER). Should match the actual system identifier. |
| Type | Required | The database platform: SQL Server, Oracle, MySQL, PostgreSQL, MongoDB, or Other. Enables platform-based filtering and DBA resource allocation. |
| Server | Required | The hosting device (linked via the Relationships tab). Critical for dependency analysis — without a server link, this database is orphaned in the dependency graph. |
| Instance Name | Optional | The named instance identifier for platforms like SQL Server (e.g., SQLPROD01\REPORTING). Used to distinguish multiple instances on the same host. |
| Size (GB) | Optional | Current database size in gigabytes. This value is used in storage capacity planning for the target environment. Keep it up to date as databases grow. |
| Backup Schedule | Optional | Description of backup frequency and timing (e.g., "Daily full at 01:00, transaction log every 15 min"). DBAs use this to confirm backup completion before migration windows. |
| RTO (hours) | Optional | Recovery Time Objective — the maximum acceptable downtime in hours. Drives migration window sizing. Low RTO databases require shorter migration windows and often need replication-based approaches. |
| RPO (hours) | Optional | Recovery Point Objective — the maximum acceptable data loss in hours. Low RPO databases require frequent backups or synchronous replication before cutover. |
| Owner | Optional | The DBA or team responsible for this database. Receives pre-migration task assignments and post-migration validation notifications. |
| Migration Plan | Optional | The intended migration approach (e.g., Rehost, Replatform to managed service, Retire). Used in planning dashboards. |
Example workflow
A DBA lead is preparing the database inventory for a migration programme involving 12 SQL Server instances spread across 6 physical servers. She navigates to CMDB → Databases and adds each instance one by one using + Add Database.
For each instance, she records the instance name (e.g., DBSRV01\MSSQLSERVER),
size in GB (from a recent SQL query), backup schedule (obtained from the backup team), and
RTO/RPO values (agreed with the business in a prior BCDR review). She assigns herself as Owner
for all 12 instances initially, planning to reassign to individual DBAs after a team meeting.
After saving all 12 records, she opens each Database Detail page and links the instance to its hosting device via the Relationships tab. She also links each instance to the applications that use it — some databases are shared by 2–3 applications, which she documents carefully.
With all relationships set, she navigates to Migrations → Capacity Planning and confirms the storage totals now reflect the full database estate. She then reviews the dependency graph: two of the 12 databases are consumed by applications assigned to Wave 2, confirming those databases and their hosting servers must also be in Wave 2.
Tips & best practices
A database record without a hosting server link is an orphan — it won't appear in device-level dependency analysis or capacity planning. Make it a rule to link the server relationship immediately after creating each database record.
RTO and RPO values inform migration window planning and tool selection. A database with RTO = 1 hour requires a very different migration approach to one with RTO = 24 hours. If RTO/RPO haven't been formally agreed, work with the business owner to define them — don't leave them blank.
Database sizes grow over time. If you recorded sizes at project kick-off and the migration is 6 months away, re-check sizes closer to the migration date. Undersized storage estimates cause failures during migration execution.
Common mistakes
A database that isn't linked to a server cannot be included in co-migration grouping logic. If the hosting server is migrated without the database record being associated, the dependency graph won't flag the risk. Always create the server link immediately after saving a new database record.
Without a backup schedule, the DBA team has no documented reference for verifying that a recent backup exists before opening a migration window. This field may seem like documentation overhead, but it becomes critical when you're 30 minutes from a cutover and need to confirm the last backup time.
The same database instance might be referred to as DBSRV01,
DBSRV01\MSSQLSERVER, 10.10.1.5, or dbsrv01.corp.local
by different teams. Choose a single canonical naming convention (we recommend
HOSTNAME\INSTANCENAME) and enforce it using normalisation rules to avoid
duplicate records.