7.0! That's a long time ago... at least 5 year old code
Here's my breakdown of trying to upgrade from 7.0:
1)
1st check that the hardware will be compatible -> check the 8.2 server sizing guide,
2)
Make sure the OS is 64-bit. From the command line:
# uname -i
If it returns 'i386' then you're on 32-bit OS. If it returns 'x86-64' then you're on 64-bit.
When both of the above check out (meaning hardware is within current required spec and the OS is already reporting as 64bit), then you can proceed with the following:
option a)
long path -> but best for making sure nothing fails between versions as far as database migration is concerned:
7.0.x -> 7.1.3 -> 7.2.5 -> 7.3.9 -> 7.4.9 -> 7.5.7 -> 7.6.6 -> 7.7.14.1 -> 8.0.11.1 -> 8.2.0.2
(9 steps - yowza!)
option b)
skipping every other upgrade:
7.0.x -> 7.2.5 -> 7.4.9 -> 7.6.6 -> 8.0.11.1 -> 8.2.0.2
(5 steps - manageable...)
option c)
start fresh with just 8.2.0.2 and then add devices from there
------------
If your OS was 32bit, then you would want to upgrade to 7.2.5, take a backup, download that backup off server, reinstall from the 7.2.5 ISO (to replace old 32bit OS with 64bit OS), and then restore the 7.2.5 backup that was generated. OS install takes about 10-15 minutes, with the amp-install portion after OS install taking the same amount of time as an upgrade.
------------
Since I'm guessing that the server is outside of spec, another alternative would be to setup the new server to run at the same time as the older production server. Export the necessary csv from the database that you can import using csv import on the Device Setup -> Add page. And then take a VRF backup from the older production and restore that backup to the new server.
If you choose to undergo the long upgrade path, you may want to open a support case so that they can provide additional guidance.