ADC Migration to AVI and F5

Consolidating an application delivery estate is a per-object slog: every virtual server has a pool, the pool has members and a load-balancing method, a health monitor, maybe a persistence profile, and — on anything fronting HTTPS — an SSL/TLS profile with a cipher string and a certificate. Doing that by hand across hundreds of virtual servers is where migrations stall.

Versus turns that into a migration plan: you point it at a source load balancer, it reads the normalized inventory Versus already holds for that device, translates each virtual server into the target platform's object model, shows you the projected build side-by-side with the source, and — for AVI targets — provisions it through the workflow engine with an approval gate. The two supported targets are VMware NSX ALB (AVI) and F5 BIG-IP.

---

What it migrates

A migration plan works at two granularities at once: object-by-object (virtual server → pool → members → monitor → persistence → SSL profile) and device-by-device (one plan sources from one device; run several plans to consolidate an estate onto one target).

Supported source vendors — detected from the device's vendor field in inventory:

Supported target platforms:

The source inventory is the same normalized VirtualServer / Pool / Monitor model every Versus collector populates, which is why one translation core works across vendors — the source is already normalized before the converter ever runs.

---

How translation works

At the heart of the feature is a small, pure converter (adc_migrate.convert_vs) with no database or network side effects. It takes one normalized virtual server plus the target platform and vendor, and returns a four-part result:

convert_vs(vs, target_platform='avi', source_vendor='netscaler', target_settings={...})
# ->
{
  'source':          { name, destination, port, protocol, vendor, pool_count },
  'target':          { ...projected AVI or F5 objects... },
  'checklist':       [ { step, label, status, detail }, ... ],
  'migration_notes': [ "Rewrite/Responder policies -> AVI DataScript or F5 iRule", ... ],
}

Load-balancing method maps from the source token to the target's enum. For AVI:

For an F5 target the method is carried through as the F5 loadBalancingMode string directly.

Health monitors map by type — for AVI, to the built-in system monitors (System-HTTP, System-HTTPS, System-TCP, System-UDP, System-Ping); for F5, to the native monitor templates (http, https, tcp, gateway_icmp, udp, tcp_half_open). When a source monitor lands on a built-in, its checklist step is marked done — there is nothing to create.

SSL detection keys off the port and protocol: a virtual server on 443/8443 gets an SSL-enabled service and a secure application profile (AVI System-Secure-HTTP, or an F5 clientssl profile). Otherwise the converter picks an HTTP or L4 profile based on protocol.

The projected target objects

For an AVI target, the converter emits a virtual_service (VIP, service port, application profile, cloud, SE-group, tenant) and a pool (name, lb_algorithm, health_monitor_refs, servers):

{
  "virtual_service": {
    "name": "web-app-vs",
    "vip": [{ "ip_address": "10.20.0.50" }],
    "services": [{ "port": 443, "enable_ssl": true }],
    "application_profile_ref": "System-Secure-HTTP",
    "cloud_ref": "Default-Cloud",
    "se_group_ref": "Default-Group",
    "tenant": "admin"
  },
  "pool": {
    "name": "web-app-vs-pool",
    "lb_algorithm": "LB_ALGORITHM_LEAST_CONNECTIONS",
    "health_monitor_refs": ["System-HTTPS"],
    "servers": [{ "ip": "10.30.0.11", "port": 443, "enabled": true }]
  }
}

For an F5 target it emits an ltm virtual + ltm pool shaped for iControl REST — destination /{partition}/{vip}:{port}, profiles (http, clientssl, or fastL4), pool loadBalancingMode, monitor, and members as ip:port strings — using the plan's f5_partition and f5_route_domain.

Migration notes

Whatever isn't a clean 1:1 translation is surfaced as a migration note rather than silently dropped or guessed. These are keyed by source vendor — for example, an F5 source flags "Review iRules — port to AVI DataScripts (→AVI) or keep as iRules (→F5)" and "Check iApp-owned objects — detach before migrating"; a NetScaler source flags content-switching vservers and rewrite/responder policies. A virtual server with no pool is always flagged for manual review. The notes are the honest edge of the tool: it translates the structural 90% and tells you exactly what needs a human decision.

---

Building and running a plan

A migration is a MigrationPlan (plan type Legacy ADC / adc_to_avi) with one MigrationItem per source virtual server. You work with it from Workflows → Migrations in the UI, or over the API under /api/devices/migration-plans/.

1. Create the plan and populate items

Create a plan naming the source_device, the target_device, and target_platform (avi or f5). Then pull in the source virtual servers — populate_items reads them straight from the normalized inventory:

POST /api/devices/migration-plans/{id}/populate_items/
{ "default_se_group": "Prod-SE-Group", "default_cloud": "Default-Cloud" }

Each imported item carries the source VS name, IP, port, protocol, and its pool members. You can restrict the import with include_vs_names.

2. Set target parameters per item

Every item has target-name fields you can override — target_name, target_pool_name, target_hm_name, target_client_ssl_name, target_server_ssl_name, target_persist_name, target_app_profile_name, target_vip, target_se_group, target_cloud. A naming convention can generate these consistently. If you use a source device that shares SSL templates across virtual servers (common on A10), sync_shared_ssl collapses them so provisioning creates one shared AVI profile instead of duplicates.

3. Review the translation

The review_detail endpoint returns the full per-VS comparison: source config beside projected target objects, the per-object checklist, and migration notes.

GET /api/devices/migration-plans/{id}/review_detail/

For an A10 source this fetches SSL templates, health-monitor names, and persistence templates live from the device so ciphers and certificate names are accurate. For other source vendors it renders the structural conversion. For an F5 target it returns the projected LTM build for each item. Where the source is an A10, a vs-status call adds a live up/down pill per virtual server, so you can see operational state at every step.

4. Assign VIPs (optional IPAM)

If items don't already have a target_vip, the plan can allocate one per item from IPAM during the run. Set each item's vip_network (a CIDR) and an ipam_device on the plan; the allocation step calls Infoblox or BlueCat to reserve the next free address and records the allocation reference for later cleanup.

5. Provision through the workflow

Execution runs as a standard Versus workflow — the built-in ADC Migration (Kemp/A10 → AVI) definition (slug adc-migration) — with the plan id passed in as migration_plan_id. Its sections are:

Validate Plan  ->  [Approve]  ->  Allocate VIPs  ->  Provision AVI  ->  Finalise

• Validate checks every non-skipped item has a target name (and, if required, a VIP), confirms a target device is set, and won't re-run items already marked migrated. Port-80 companions of a port-443 VIP are detected and folded into the SSL virtual service automatically.
• Approve is a manual gate — the run pauses until an operator approves, so nothing is created on the target without sign-off.
• Allocate VIPs fills in any missing VIPs from IPAM.
• Provision AVI connects to the target AVI controller and creates each pool and virtual service in dependency order — reusing existing health monitors, SSL profiles, and persistence profiles by name where they already exist rather than duplicating them, and uploading certificates as needed. For A10 sources it additionally resolves SSL client/server templates to cipher-accurate profiles and classifies aFleX into native features or DataScripts.
• Finalise tallies migrated/failed/skipped and sets the plan status to completed or failed.

Because it's an ordinary workflow run, you drive it exactly like any other automation — trigger it, watch it section-by-section, approve the gate, and retry a failed step — from the UI or the Workflow API. Run the Provision step with dry_run enabled first to log everything it would create without touching the target.

Each item advances through pending → ready → migrated (or failed / skipped), so the plan is a durable, resumable record of exactly what was built.

---

How it fits the platform

ADC migration is not a standalone tool — it stands on the rest of Versus:

• Inventory is the source of truth. Discovery is fast and device-by-device because the converter reads the normalized VirtualServer / Pool / Monitor inventory the collectors already keep current; live device calls are only made to fetch vendor bodies the normalized model doesn't carry (A10 SSL cipher templates, aFleX bodies).
• Credentials for source and target devices come from the Secret Vault — the migration code never holds a password itself.
• Collectors reach both the source and target devices from inside your network, so a migration plan works the same whether Versus runs in the cloud or on-premise. See Collector Fleet.
• Certificates required by a translated SSL profile are handled through the platform's certificate lifecycle rather than copied by hand.
• Workflows provide the execution, approval, retry, and audit trail — a migration run is a first-class workflow run, visible and governable like every other change.

The result is that consolidating onto AVI or F5 becomes a reviewable, approvable, resumable change instead of a spreadsheet and a long weekend.

---

Related

• F5 BIG-IP Integration — the on-prem ADC counterpart, as a migration source or target.
• Certificates — certificate lifecycle for translated SSL profiles.
• Secret Vault — where source and target device credentials live.
• Workflow Builder — the engine that runs the migration, and naming conventions.
• Running Workflows via the API — trigger and supervise a migration run programmatically.
• Collector Fleet — how Versus reaches source and target devices.