Submit a ticketCall us

Looking to compare latest NPM features with previous versions of NPM?
The NPM new feature summary offers a comparison of new features and improvements offered with this release.

 

Home > Success Center > Network Performance Monitor (NPM) > Newly installed applications and migration caveats for staging, database merges, etc.

Newly installed applications and migration caveats for staging, database merges, etc.

Table of contents
Created by Daniel Polaske, last modified by MindTouch on Jun 23, 2016

Views: 6 Votes: 0 Revisions: 4

Overview

This article provides information about newly installed applications and databases where they may be preferable to a migration. This is either due to a pre-existing need to audit the database for stale or unnecessary data, or simply to mitigate the effects of iterative upgrades applied over a long time frame. 

For example, as for any program - a fresh install using only the latest binaries tends to be more stable than an application server that has been continuously patched and upgraded through multiple release cycles.

Environment

All versions of Orion products

Detail

Here are some caveats for this:

1.  Unfortunately, there is no way to selectively import, merge or splice information from an existing database into a fresh one. The only way accomplish your goal would be to do a in-depth audit of your existing configuration to remove unneeded custom fields/properties or other data from the database. Otherwise, you would need to start with a fresh database using the Configuration Wizard.

 

2.  For the purposes of staging and graceful switchover, an evaluation install will last for 30 days but in some cases sales can generate longer-lasting temp keys, keep in mind that if the versions are going to stay the same, or if you can upgrade the versions while still connected to your existing database (so that the schemas are up to date) and then create a new database, you can always use your existing installation and just re-connect to the old database. The caveat for this is that you wouldn't be able to use both databases at the same time i.e. gaps in polling for times when you connect to the old database, stale node data (missing nodes in the new/old database) etc.

 

3.  There is no way to connect two Primary Polling Engines to the same database, however you could technically do this if you made a copy of the database and connected to the database "one-to-one" with two Primary Polling Engines with the same versions and matching database schemas.

 

Note: The application version always needs to match the versions that were connected to the database as the schema goes one way. You can't connect older versions of the application to a database that was connected to newer versions and vice versa.

 

Last modified
22:49, 22 Jun 2016

Tags

Classifications

Public