Migrate Proxysg from 6.7.5.x appliance to virtual 7.3.11.x - best approach?

[JS_2022]

We are upgrading our proxysg appliances (running 6.7.5.12) to new virtual proxies (currently running 7.3.11.x). I know there are some differences with how 7.3.x works. Would it be better to build the new virtual proxies with the samde code as the appliances (6.7.5.12) and then do an OS upgrade on the virtuals to 7.3.11.x? Or should I just leave them as is with different OS versions and follow the backup/restore procedure outlined in Article ID: 165985.

Thanks

[Jacob Miles]

Hi JS,

I hope you are well. There are two separate ideas at play:

1) Upgrade from SGOS 6.7 to SGOS 7.3

2) Migrating from existing hardware appliances to virtual appliances.

My recommendation would be that when migrating, to have both legacy and new appliances on the same version of code. That means you could migrate now with both old and new boxes on 6.7, and then upgrade to 7.3, or you could upgrade the old boxes to 7.3 now, and migrate to virtual appliances running 7.3 later.

With that said, do take into account SGOS 6.7 will be EOL Dec 31, 2023. I would also imagine your legacy boxes might be coming up on EOL as well. Be sure to factor those dates into your planning to make sure you are running supported appliances on supported code.

I hope that helps!

[JS_2022]

Thanks Jacob. I should have also added that we have a new management station as well. My concern was that if I imported the existing 6.7 policies to the management station and then applied them to the new 7.3 virtual proxies they would not work properly.

[Klaus Klinge]

Hi Jeff,

If you import the ruleset from version 6.7 into the Management Center and then upgrade to 7.3 - and you suspect that the policy will no longer work after that - then simply re-import the ruleset from the proxy after the upgrade.

I recently had a related issue:
I had an ASG that needed to be replaced with a ProxySG and a CAS.
Here I had to duplicate the ruleset because you can't roll out an ASG ruleset to a ProxySG. 
The reason is the virus scanner - for an ASG the rule for the local virus scanner looks like this:
response.icap_service(bluecoat-local-response,fail_closed)
and you can't name the AV service exactly like this on the ProxySG, because there are no "-" allowed, only "_".
So I copied the ruleset on the management center and then had an ASG version and a SG version. 
I could have changed the ASG to use the CAS of the ProxySG - but for that I would have needed an additional Change (strictly according to ITIL).
Best regards,
Klaus

[Charbel Lahoud]

Hello if i have SGOS 6.7.5.12 SWG Edition running on a Virtual appliance. what is the best way to upgrade to 7.3.12.1

do i need to back up the configuration from the CLI?GUI and start a new image running version 7.

or i can simply upgrade it from the Virtual Host ?

[JS_2022]

Hi Jacob,

Thanks for the reply. I have been doing some reading about upgrading from 6.x to 7.x. - I do not see a Hyper-V based version for 6.7.x. Is it not available or am I just not entitled? My preference would be to have both the existing appliances and new VMs at 6.7.5.x, migrate the entire config from appliance to VM, and then upgrade the VM's (keeping them out of production) so that I can verify all is well.

If there is not a Hyper-V version of 6.7.5 then it seem that the best approach, as you stated, would be to upgrade the existing appliances to 7.x and then migrate their config's over the the new VM's (which will have the same SGOS).

As going from 6.x to 7.x is a MAJOR OS upgrade I want to be sure I won;t run into any issues after the upgrade on the existing appliances. We use external CAS units for content analysis and I thought I had read that this feature is now part of the policy or something and that I may have to disable some NEW layers after the upgrade?