Looking at your licensing, it appears that you have a fairly simple environment. If so, this doesn't have to be complex at all since the customer doesn't need any of the existing data. The simple solution would be to document your settings, approach this as a fresh install, and put your settings back.This will bypass any need for migration tools that might be needed to convert your database and save archives. I have no experience with these tools, so I'm not sure of their full capabilities.
About a year ago, due to learning the system and some poor configuration choices on the disk, I needed to migrate my 7.0 cameras to a new 7.2 system that was configured correctly. Here's how I did it.
1) Document, document, document. Take screenshot of all your settings. Take a backup of the database. Document the number of cameras you have, the number of templates, number of encoders, etc. This data will be used for verification after your migration.
2) Connect to the MySQL database and write queries to obtain the necessary information that is needed to do a bulk import (using Excel) of your cameras, encoders, templates, etc. Below is the SQL I used for my IP cameras. Note: Since analog cameras are configured differently, I used a seperate SQL for these. You should have a seperate SQL for each device type. Copy the results into an Excel spreadsheet.
***********************************************
****** List IP Cameras **********************
***********************************************
select a.name, a.model,
d.ipaddress,
e.name as 'Template',
f.name as 'Server',
(select name from groupinfo where objectid = a.location_objectid) as 'location',
(select name from groupinfo where objectid = a.pointtolocation_objectid) as 'pointToLocation'
from camera a,
networkconfig b, networkconfig_network_interface c, network_interface d,
devicetemplate e,
server f
where a.networkconfig_objectid=b.objectid and
b.objectid=c.networkconfig_objectid and
a.networkconfig_objectid=b.objectid and
c.networkinterfaces_objectid=d.objectid and
a.devicetemplate_objectid=e.objectid and
a.managedby_objectid=f.objectid and
a.objecttype=6
order by location;
3) Build out the new system using VMWare (or some other virtualization solution) to test your configurations that you saved in Excel. (This will also let you get the new spreadsheets so you can know what data you need for the import.) This will help you ensure that you do not have any syntax errors. For us, we were migrating from virtual to virtual, so the system we tested on became our new PROD and we simply deleted the old VMs after verifying the new worked. Do not have your cameras run on both systems though. From my experience, you will be fine to pre-provision the cameras to the test system, but do not have streams going to both simultaneously.
4) After you have tested your install and configurations, perform a full install on your Production system and load your configs.
This process worked extremely well for me because we have a fairly simple configuration. All our cameras are Cisco except for a few analog cameras that have been connected to Cisco-encoders. We have only two templates, which we documented manually instead of writing SQL since there were so few. Since we were virtualized, we could easily keep PROD up while we pre-provisioned the new system. If something didn't work, we could easily revert to the old system. I highly recommend testing this in a virtual lab first, because from my experience, I had to go through a couple of iterations in my SQL code to format the data and capture what was needed properly. The syntax can be a bit tricky your first time through. Also, verify (using the 7.2.1) release notes that all your devices are supported and at a supported level of code. For us, some of our cameras were not at supported levels and experienced dropped frames every few seconds until we upgraded these to supported code.
If your config is complex and you don't feel comfortable with the above steps, I recommend going with Scott's solution and seek help from a third party. Also, according to my recent conversation with TAC, skip 7.2.0 and go straight to 7.2.1. Apparently, there was a bad bug in the first one that, if encountered, could result in the loss of archives.
Hope this helps.
