Migrating Devices Between VigorACS Servers

Best Practices, Migration Checklist, and Mass Migration Procedures

Migrating devices from one VigorACS server to another is a common task during infrastructure upgrades, server replacements, cloud migrations or environment consolidation. Although the migration process is straightforward, careful planning is essential to avoid device disconnects, failed provisioning or loss of management access.

This guide covers key considerations, pre-migration checks, and a recommended mass migration approach using VigorACS provisioning.

1. Key Considerations Before Migration

Before migrating any devices, review the following areas to minimize risk and ensure a smooth transition.

• Server Readiness

       Verify that the target VigorACS server is fully operational:

• Accessible from the Internet or relevant management network
• SSL certificates are installed and valid
• Required firewall ports are open
• DNS records are configured correctly
  • Configuration Consistency

Ensure the target server contains:

• User accounts and permissions
• Device groups and organizational structure

• Device compatibility

        Confirm that:

• Device firmware versions are supported
• Devices can resolve and reach the new ACS URL
  • Backup and recovery

Before making any changes:

• Backup the source VigorACS database
• Document the existing ACS URL and credentials
• Prepare a rollback procedure

2. Migration Strategy Options

Option A: Direct ACS Switch via Provisioning (Recommended)

This is the recommended approach for most deployments.

The source VigorACS server pushes a new ACS URL to managed devices using a provisioning profile. Once applied devices reconnect to the target ACS server during their next inform session.

Typical workflow

• Device connects to the source ACS.
• A migration preset updates the ACS URL.
• The device stores the new ACS settings.
• The device reconnects to the target ACS.
• The target ACS adopts and manages the device.

Considerations

• Devices must be online and communicating with the source ACS.
• Provisioning should be tested on a pilot group first.

Option B: DNS-Based ACS Migration

If devices are configured to use a hostname rather than a fixed IP address, DNS can be used to redirect devices to the new ACS server.

Example

Current ACS URL:

https://acs.company.com

Migration process:

1. Deploy and validate the target ACS.
2. Update the DNS record to point to the new server.
3. Monitor incoming device connections.

Considerations

• Devices must use a hostname-based ACS URL.
• SSL certificates must match the hostname.
• DNS propagation timing should be considered.

3. Mass Migration Using Provisioning

For large deployments, devices should be migrated in controlled batches rather than all at once.

Step 1: Create a Migration Provisioning profile

• Create a profile that updates:
• Management Server URL
• Management Server Username (if required)
• Management Server Password (if required)

This profile should point devices to the new ACS server.

Step 2: Perform a Pilot Migration

Apply the preset to a small group of devices.

Recommended pilot size:

• 10 devices
• 50 devices
• 100 devices

Validate successful migration before proceeding.

Step 3: Migrate in Phases

A staged rollout minimizes risk and reduces load on the target ACS.

Suggested rollout:

Step 4: Monitor Migration Progress

Continue…

Track:

• Devices successfully adopted by the new ACS
• Devices remaining on the old ACS
• Failed provisioning attempts
• Offline devices

4. Validation Checklist

After each migration phase, verify the following.

Device Connectivity

• Devices appear on the target ACS
• Devices continue sending Inform messages
• Devices can be queried successfully

Authentication

• ACS credentials are accepted
• No authentication errors are reported

Monitoring

• Online/offline status updates correctly
• Alerts and monitoring functions operate normally

Performance

• Target ACS handles expected device load
• No excessive CPU, memory or database utilization

5. Rollback Strategy

Always plan rollback:

• Keep the original ACS server operational until all devices have been successfully migrated and validated.
• Retain a provisioning profile that can restore the original ACS URL if required.
• Monitor migration progress and stop further migration batches if unexpected issues occur.
• If a rollback is needed, apply the rollback profile to affected devices to point them back to the original ACS server.
• Verify that devices reconnect successfully and resume normal management on the original ACS.