Table of Contents

Sonar to Sonar Instance Onboarding

Alex Moore Updated by Alex Moore

Read Time: 5 mins

The purpose of this article is to explain the approach taken by the Sonar team when importing one Sonar instance into another, as well as explain some of the translations in data and considerations that must take place.

Basic Explanation of Methodology

If we were to attempt a direct copy of the data tables from one Sonar instance and copy them into another, there would be all sorts of duplicate IDs which would cause a variety of bugs, issues, crashes, and general problems. Because of this, we instead use the API to export data tables from the instance to be imported, make translations as needed to IDs or other unique fields, then use the API to get the data back into the instance we are importing into.

Important Considerations

  1. Only one payment processor can be operating at one time. In almost all cases you will want to migrate any payment methods so that both instances are using the same credit card and bank account processors prior to any migrations.
  2. There are many, many data tables in Sonar instances that will start counting from 1 as new fields are created in the software. These IDs are going to change for most or all of the data coming from the imported server.
  3. Any internal network IPs on the imported network must be changed so that they do not overlap with any assignments in the importing network. It is best to make these network-level changes prior to migration.
  4. The day the accounts first bill in the new system it will be under the new branding, email messaging, etc. Consider and execute your messaging to your customers ahead of that time to explain this change.
If you want to have two separate brands going forward, this can be done using separate companies, but we will need to start the top of the project knowing this. They will still need to use the same payment processor.
  1. Because these migrations almost exclusively take place in two production environments, the actual export and import of any templates need to take place in a relatively narrow timeframe to avoid creep. This sometimes means bringing in data sets in stages (see Data Imports by Priority header below).
  2. Because of the methodology, historical transactions will not be migrated, only account balances (see Data that Does Not Migrate header below).
  3. Sonar can host the old instance in a test mode non-billing state for the monthly minimum charge if you wish to keep it as a source of record.

Data Imports by Priority

Primary Data Tables

These are the data tables that are required in order to automate billing as well as provisioning. They are the data sets that need to be brought in quickly and accurately for any and all migrations. If they have data, they should almost always be migrated 1 to 1 with the exception of ID changes. These tables are as follows:

Required for Billing
  • Serviceable Addresses
  • Accounts (Groups, Types)
  • Account Mailing Addresses
  • Account Billing Parameters
  • GL Codes
  • Services
  • Taxes
  • Service Taxes
  • Packages
  • Account Services
  • Account Packages
  • Tokenized Bank Accounts
  • Tokenized Credit Cards
Required for Provisioning
  • Inventory Models
  • Inventory Model Fields
  • Network Sites
  • Inventory Items
  • Subnets
  • IP Pools
  • MAC Address IP Assignments
  • IP Assignments
  • Account Balances
Account Balances will always be the final primary data table imported so that they can be exported right before the old instance billing is disabled and quickly imported into the new instance.

Secondary Data Tables

  • Tickets
  • Account Notes
  • Contacts
  • Account Custom Fields
  • Files
Often there can be several GB of files to move. We usually move this data last as its own project because if there is any sort of size to the file directory it will often be quicker to import all other data sets combined in the same timeframe.

Data That Does Not Migrate

  • Historic Transactions
  • Historic IP Assignments
  • Completed Jobs
  • Logs
  • Custom Reports

Data That Does Not Migrate, But Can be Easily Added

  • Users
  • Supernets
  • Job Types
  • Scheduled Jobs
  • DHCP Servers
  • Inline Devices
  • RADIUS Servers
  • Webhooks

Basic Outline of Onboarding Events

  1. Talk with your Client Experience Manager and let them know the desired timing of the migration, as well as any secondary data tables you might require. They will book time with our Technical Advisors to facilitate the timing requested.
  2. As soon as possible, begin the work to migrate the payment processors and any internal IP address changes that need to take place on the instance that is to be migrated, as these processes are the most time-consuming in any project.
  3. Our team will take an initial export for all applicable primary data tables from the instance to be imported. If there are any duplicate IPs, we will advise on these. Once we are happy with the data, we will set an export date for our team to begin copying the data and a go-live date that we expect the data to be ready for billing in the new system. Any new accounts or services created beyond the export date in the old instance will need to be recorded and manually entered into the new system on the go-live date prior to the balances import.
  4. On go-live, it will be the responsibility of your team to import any new accounts. Once this is done, let us know and the Sonar team will import balances as the old system is turned down while both parties are on a call.
  5. Any additional data requirements can be scoped, discussed, and executed until we are satisfied to turn down the old server.

How did we do?

Submitting Bugs vs. Feature Requests

Third Party Customer Support Referrals