Migrating ServiceNow On-Prem DB from MariaDB to PostgreSQL during ITOM implementation

[AdeelB]

I am currently implementing ITOM (Discovery and service Mapping) on a Self-Hosted (On-Premises) ServiceNow Instance. The current backend is MariaDB, and we are planning a migration to a different DB engine (considering PostgreSQL).

Given the On-Prem nature of our deployment, I have the following technical questions:

• Migration Risk: Since ITOM creates complex dependencies in the CMDB, is there a risk of data corruption or metadata loss for Patterns and Service Maps during a DB-level migration?

• Database Choice: Is PostgreSQL the recommended alternative for On-Prem environments to ensure better performance for Discovery's high-frequency inserts/updates?

• Workflow Impact: Are there known issues with the MID Server communication or Discovery Probes when the underlying DB architecture changes mid-project?

We are looking for insights from architects who have managed DB migrations in a Self-Hosted ServiceNow environment.

[yvijay]

Hello @AdeelB ,

To successfully navigate this migration without derailing your ITOM rollout:

1. Pause Active Discovery & Service Mapping: Freeze all new ITOM Discovery & Service Mapping definition pipelines. Export existing custom Patterns, Identification and Reconciliation Rules (IRE), and CSDM models into a dedicated Git branch or external XML file store. 
2. Align with ServiceNow Support: File a high-priority support case to obtain the certified target versions and architecture requirements for your On-Premise environment. 
3. Execute in Staging First: Perform a comprehensive sub-production migration. Run high-frequency, full-subnet Discovery schedules in the test PostgreSQL/RaptorDB sandbox environment to validate that row-locking, transaction processing speeds, and ECC queue clearance meet performance metrics

If this was useful, please consider marking it as Accept as Solution and Helpful.

Thanks, 

Vijay

[fknell]

Hi @AdeelB,

I would recommend opening a case with ServiceNow. There is a standard way to migrate instances, and I would recommend setting up a fresh instance and following the instructions given by ServiceNow. A database migration I would not recommend; let the instance/application layer handle the database portion of the migration.

Hope this helps!