Direct answer: what this migration service covers
It is a controlled transition from legacy HPE Aruba or related HPE campus networking platforms to a current, supportable wired and wireless architecture, without assuming that old configuration can simply be copied into the new platform.
It reduces lifecycle, support, capacity and operational risk while preserving required VLANs, routing, authentication, voice, wireless, uplinks and business connectivity during a planned refresh.
UAE organisations running ageing ProCurve, ArubaOS-Switch, legacy Aruba WLAN, mixed generations of Aruba hardware, or networks whose configuration and documentation no longer match the operational reality.
Confirm the real dependencies before selecting replacement hardware: port counts, PoE draw, uplinks, VLANs, Layer 3 functions, stacking, optics, authentication, AP power, WAN handoffs and management subscriptions.
FourTeck can help establish the migration scope, target family, port and power requirements, management model, subscription needs, staging approach, cutover sequence and quotation inputs.
Why legacy Aruba migrations need design work, not just hardware replacement
A legacy network can appear simple from a rack view: several switches, access points, uplinks and perhaps a controller. Operationally, however, years of changes may have embedded dependencies that are not obvious from the current diagram. Voice VLANs may rely on LLDP or vendor-specific behaviour. Access ports may carry manually applied ACLs. Uplinks may depend on spanning-tree priorities that were never documented. Wireless SSIDs may map to VLANs that exist only in selected buildings. DHCP relay, static routes, OSPF adjacencies, VRRP, link aggregation, multicast settings, RADIUS servers and management access can all be part of the real service chain.
AOS-CX is not simply a renamed continuation of every historical ArubaOS-Switch or ProCurve command model. Likewise, a wireless move can involve a change in control, licensing, management and policy architecture rather than a direct one-for-one AP swap. The practical objective is therefore to preserve required business outcomes while deliberately redesigning the parts that should not be carried forward. That distinction is central to a safe migration.
For UAE organisations with multiple offices, warehouses, hospitality sites, schools, healthcare facilities, retail branches or industrial locations, migration sequencing becomes especially important. A refresh may need to maintain links to firewalls, IP telephony, CCTV, access-control systems, printers, building systems and WAN circuits while individual floors or sites are converted. The migration plan should be based on the actual dependency map, not only on the age of the switching hardware.
What the discovery phase should prove
Discovery is where migration risk is converted into facts. The goal is not merely to list serial numbers; it is to understand what each legacy device is doing, which services depend on it and what the target platform must reproduce or improve.
Switch and AP models, part numbers, stack membership, uplink modules, transceivers, DACs, power supplies, rack position and patching.
VLANs, trunks, native VLANs, LAGs, routing, gateways, ACLs, DHCP relay, DNS/NTP, SNMP, syslog, AAA and management paths.
User ports, phones, cameras, APs, IoT devices, printers, servers and specialist equipment, including current and expected PoE draw.
RADIUS/TACACS+, ClearPass or other NAC, firewall interfaces, WAN handoffs, monitoring tools, backup systems, API integrations and support processes.
Typical legacy estates and how the migration path differs
| Legacy condition | Migration focus | Key checks before cutover |
|---|---|---|
| ProCurve / older ArubaOS-Switch access layer | Translate port, VLAN, trunk, STP, LAG, security, QoS and management behaviour into the selected AOS-CX design. | Port density, PoE budget, uplink speed/media, optics, stack design, voice behaviour, route dependencies and unsupported legacy features. |
| Mixed ArubaOS-Switch and AOS-CX | Standardise templates, firmware strategy, monitoring, authentication and operations while allowing phased hardware replacement. | Interoperability, spanning-tree roles, LACP, routing adjacencies, Central support, site/group design and change control. |
| Legacy controller-based Aruba WLAN | Decide whether to retain supported controller architecture, move to a newer Aruba WLAN design, or adopt a Central-led target based on AP support and requirements. | AP models, software support, SSIDs, authentication, roaming, VLAN tunnelling/bridging, guest access, RF design and gateway/controller dependencies. |
| Older Instant / branch deployments | Assess AP hardware support, configuration equivalence, cloud onboarding, site structure and operational ownership. | Internet reachability, subscriptions, SSID policy, local survivability, gateway design and migration order. |
| Mixed-vendor edge around Aruba core/access | Preserve standards-based interoperability and identify proprietary features that may require redesign. | LLDP, LACP, STP variants, routing protocols, 802.1X, VLAN tagging, optics and management boundaries. |
AOS-CX switching migration: translate intent, then validate behaviour
For many wired refresh projects, the target will include HPE Aruba Networking CX switches selected according to access, aggregation, core or data-centre requirements. The correct family cannot be chosen from old model numbers alone. Access switches must be sized for port count, PoE class and total power, multigigabit requirements, uplink bandwidth and stacking or redundancy expectations. Aggregation and core selection depends more heavily on throughput, high-speed interface requirements, routing scale, resilience, architecture and growth.
Configuration translation should be based on intent. For example, a legacy trunk may carry a native VLAN plus several tagged VLANs; the migration engineer must reproduce the intended forwarding behaviour using the target platform’s model and verify it with an endpoint and uplink test. A legacy static LAG should not automatically be recreated if the intended design is actually LACP. A spanning-tree configuration should be reviewed together with root placement and redundant paths rather than copied line by line. The same principle applies to ACLs, QoS, DHCP relay, management access and routing.
Stacking and high-availability choices also need explicit planning. Depending on the selected AOS-CX family and architecture, technologies such as VSF or VSX may be relevant, but they are not interchangeable and they do not apply identically across all switch series. Replacement hardware, software alignment and member procedures can also have platform-specific requirements. The migration design should therefore identify the exact switch family, software train and resilience method before staging.
Wireless migration: confirm AP support, control model and user experience
Hardware eligibility
Do not assume that every installed Aruba AP can be carried into the chosen target software and management architecture. AP model, memory variant, minimum software release and last supported release should be checked against current HPE support documentation.
SSID and policy translation
Inventory SSIDs, authentication methods, VLAN assignments, guest flows, captive portals, role policies, RADIUS servers, certificates and application dependencies. Wireless migration fails when only the RF layer is considered.
RF and PoE readiness
Newer APs may change PoE and multigigabit demands. Validate switch power budgets, cabling category, uplink capacity, mounting, channel planning and coverage. A hardware refresh should not preserve a poor RF design simply because the AP locations already exist.
Cutover coexistence
For multi-floor or multi-site environments, old and new wireless systems may coexist during migration. Roaming expectations, SSID consistency, DHCP scope capacity and authentication behaviour should be tested before a mixed period is accepted.
HPE Aruba Networking Central: management migration is a project of its own
HPE Aruba Networking Central is designed to provide centralised configuration, management and monitoring for supported HPE Aruba Networking infrastructure, but the migration must account for device support, subscriptions, inventory, groups, sites and the configuration model. Current HPE guidance for newer Central workflows explicitly distinguishes onboarding from automatic configuration conversion. That matters for legacy migrations: the presence of a device in a management platform does not prove that every historical configuration element has been translated.
A sound Central plan starts by confirming which devices are supported in the intended Central environment and software release. Next, define the organisational structure: sites, device groups, naming standards, roles, administrative boundaries and configuration objects or templates. If the business already uses Classic Central, the project should separately address migration of configuration and day-two workflows such as monitoring, reporting and troubleshooting. API integrations, alerting, logs and operational procedures should be listed before the old platform is retired.
Subscriptions also affect the final design and quotation. HPE documents Foundation and Advanced subscription tiers across infrastructure categories, with feature differences that can change over time. The required tier should be determined from the actual feature set, device type, management model and term rather than assumed from the old licence. When advanced networking, NAC, AI-assisted operations or other premium capabilities are part of the target, current ordering guidance should be checked at quotation stage.
Port, PoE, optics and cabling checks that prevent expensive surprises
Legacy switch replacement is frequently delayed by physical-layer assumptions. A 48-port PoE switch is not automatically equivalent to another 48-port PoE switch. The total PoE budget, per-port power class, number of powered endpoints, redundancy of power supplies, uplink interface type and available transceiver slots can change whether a proposed model is suitable. Wireless access points, video cameras, door systems and phones may draw different power during normal operation, boot or feature activation.
Uplink media should be audited rack by rack. Record whether links are copper, multimode fibre, single-mode fibre, DAC or another supported medium, along with speed, distance and the exact optic or cable at each end. Reusing an optic simply because it fits physically is not a reliable design method. Compatibility, wavelength, connector type, fibre plant and platform support need to align. Where the target introduces faster uplinks, the existing fibre path and patching should be validated before cutover night.
Copper cabling deserves the same attention. If the new WLAN design expects multigigabit Ethernet or higher PoE levels, the existing horizontal cabling and patch panels may become part of the migration scope. A network upgrade that ignores structured cabling can result in a modern AP or switch operating below the intended capability.
Security and access control must survive the cutover
Many mature Aruba environments use more than simple VLAN assignment. 802.1X, MAC authentication, RADIUS attributes, downloadable or local roles, ACLs, guest services, device profiling, dynamic segmentation, ClearPass integrations or other NAC functions may be present. Even when these features are only partially deployed, their dependency chain should be mapped before access switches or WLAN control are replaced.
The migration test should include representative endpoint classes: corporate laptops, phones, printers, cameras, wireless clients, guest devices and any specialist equipment that uses static addressing or unusual authentication. Validate successful authentication, correct VLAN or role assignment, DNS and DHCP operation, application reachability, internet policy, voice registration and monitoring visibility. A port coming up is not the same as the business service working.
If the target design introduces Central NAC, ClearPass changes or a new segmentation model, treat that as a policy project rather than hiding it inside a hardware refresh. It may be safer to stabilise the new switching and WLAN layer first, then activate new policy controls in a controlled phase. The opposite may also be justified when policy migration is inseparable from the architecture. The correct sequence depends on the existing dependency map and acceptable risk.
A practical migration journey for UAE sites
Identify locations, critical services, outage tolerance, change windows, support requirements, growth horizon and whether the project covers switching, WLAN, management, NAC, structured cabling or all of them.
Collect inventories and current configurations, then confirm them against the live network. Review topology, VLANs, port utilisation, PoE, uplinks, routing, WLAN, authentication, monitoring and operational dependencies.
Select the appropriate HPE Aruba Networking families and supporting items based on requirements rather than model-name replacement. Define subscriptions, optics, power, mounting, licensing and any gateway or controller components.
Build the new configuration using the target platform’s intended model. Document any feature that must be redesigned, removed or replaced rather than forcing a legacy command concept onto the new platform.
Upgrade or align software as required, claim devices to the appropriate management inventory, apply licences or subscriptions, create stacks or redundancy where applicable, load configurations and test critical functions before dispatch or rack installation.
Use a representative but manageable site, floor or network segment to prove the runbook. Capture timings, surprises and rollback thresholds so the broader deployment benefits from real evidence.
Execute the approved sequence with pre-checks, change records, labelled patching, test cases and clear decision points. Avoid turning a multi-site refresh into one oversized change window unless the architecture genuinely requires it.
Verify monitoring, backups, alerting, authentication, documentation and support access. Record final port mappings, software versions, subscriptions, serials and architecture so the new environment starts with a reliable baseline.
Cutover and rollback: define the threshold before the outage begins
A rollback plan is valuable only when it is practical. Before the maintenance window, identify what will trigger rollback, how long restoration of the old equipment takes, which configuration backups are required, how patching will be reversed and who can make the decision. If an old stack or controller is removed without a realistic method to restore service, the document may describe rollback without actually providing it.
Pre-cutover checks should confirm backups, console access, management reachability, device licences, correct software, target configuration, optics, patch leads, rack power, labelling, monitoring and the availability of required technical contacts. Post-cutover checks should validate more than ping. Test user authentication, DHCP, DNS, internet access, key internal applications, voice, printers, wireless roaming where relevant, surveillance or IoT traffic, routing neighbours, redundancy and monitoring alerts.
For sites with strict uptime requirements, the architecture may justify parallel build, temporary uplinks or staged migration of endpoint groups. In other environments, a concise maintenance window with a rehearsed rollback is cleaner. The design should match the risk profile rather than default to the most complex method.
Migration testing: what “successful” should mean
Expected links negotiate correctly, PoE endpoints remain powered, no unexpected errors appear and uplinks operate on the intended media and speed.
VLAN membership, tagging, LACP, spanning tree, MAC learning and redundant paths behave according to the design rather than merely appearing “up”.
SVIs, default routes, static routes, dynamic adjacencies, DHCP relay and gateway redundancy operate where they are part of the target architecture.
Representative users and devices authenticate, receive the expected role or VLAN and can reach only the services intended by policy.
Required SSIDs are visible, clients associate, obtain addressing, authenticate, roam and reach business services with acceptable performance.
Devices are visible in the intended management platform, alerts reach the right team, logs are available, backups exist and administrators can access the environment securely.
UAE multi-site planning: standardise without pretending every site is identical
A UAE migration may span a head office, branches, showrooms, warehouses, hospitality locations, campuses or remote facilities. Standardisation is useful because it simplifies templates, spares, documentation and support. However, forcing every location into one hardware profile can be inefficient. A small branch with modest PoE demand does not need the same access platform as a high-density office floor, and a core or aggregation role should not be sized from user-port counts.
Create site classes where practical. A branch profile might define the required access ports, AP count, PoE reserve, WAN/firewall handoff, management method and spare strategy. A campus profile may add redundant aggregation, higher-speed uplinks, separate building distribution and more formal resilience. Warehouses may place greater emphasis on long RF cells, rugged physical conditions, scanners and cameras. Hospitality or education sites may have dense guest or student wireless loads and different segmentation requirements.
The rollout sequence should consider travel, site access, working hours, business peaks, maintenance permissions and availability of local hands. These are operational planning inputs rather than product specifications, but they strongly affect a realistic quotation and implementation schedule.
Documentation and handover should improve on the legacy environment
A successful migration is an opportunity to reset documentation quality. The final package should reflect the network that was actually deployed, not only the initial design. Useful outputs can include physical and logical diagrams, device inventory, serial numbers, management addresses, switch roles, stack or resilience membership, uplink maps, VLAN and IP plans, routing summary, SSID mapping, authentication dependencies, software versions, subscription information, configuration backups and a record of any temporary migration settings that must later be removed.
Operational handover should also cover how administrators reach the platform, where alerts are received, which accounts or roles are used, how configuration changes are governed, how firmware is handled and what information should be collected before opening a support case. If HPE Aruba Networking Central is part of the final design, ownership of the HPE GreenLake workspace, device inventory, subscriptions, groups and sites should be clear.
The value of this work appears later, during incidents and future expansion. Accurate records shorten troubleshooting, reduce dependence on individual staff memory and make the next refresh easier to plan.
When a straight Aruba refresh may not be the right answer
This service is intended to help the buyer reach a supportable design, not to force a predetermined bill of materials. A straightforward move to current HPE Aruba Networking switching and wireless may make sense when the existing operational model, skill set, integrations and feature requirements align well with the current portfolio. It can also reduce migration complexity when standards and management practices are already familiar.
A larger Aruba model should be considered when the planned device count, PoE demand, uplink capacity, routing role, redundancy, interface mix or growth requirement exceeds the selected platform. A smaller model may be appropriate where a proposed switch is being used only for basic access and provides unnecessary capacity or cost. For WLAN, AP generation and model should reflect client density, radio requirements, power and cabling rather than simply matching the number of old APs.
A different architecture may also be justified if the organisation is changing its WAN, security, NAC, cloud operations or data-centre strategy at the same time. In that case, the migration should be evaluated as part of a wider network transformation. Separating decisions that can safely be phased from those that are tightly coupled often produces a lower-risk programme.
Questions buyers should ask before approving a migration quotation
A quantity-only estimate can miss different PoE budgets, uplink modules, stack types, unsupported APs or non-standard devices hidden in smaller sites.
Validate active ports, spare capacity, PoE usage and growth rather than purchasing an assumed one-for-one replacement.
Confirm both ends of every important uplink, required speed, fibre type, distance and compatible transceivers or DACs.
The quotation should make clear whether it covers discovery, design translation, staging, cutover and testing, not only hardware installation.
Management licensing, inventory assignment, group/site structure and onboarding work should be explicit if Central is part of the target.
Ask how service will be restored if a critical dependency fails and what objective condition triggers the rollback decision.
Frequently asked questions
Can an old ProCurve or ArubaOS-Switch configuration be copied directly to AOS-CX?
It should not be assumed. The safer approach is to interpret the existing configuration, identify the intended network behaviour and rebuild that intent using the target platform’s supported configuration model. Commands, defaults and feature implementation can differ.
Can legacy and new Aruba switches coexist during a phased migration?
Often yes, provided the required standards-based features and topology are compatible. Interoperability should be validated for VLAN tagging, LACP, spanning tree, routing, authentication, optics and management before the mixed period is approved.
Does moving to HPE Aruba Networking Central automatically migrate all legacy configuration?
No universal automatic conversion should be assumed. Current HPE guidance for onboarding AOS-CX and AOS-S into newer Central workflows notes that automatic configuration migration from Classic Central groups is not currently supported in those workflows. Device onboarding, configuration translation and day-two operations therefore require separate planning.
Do Central subscriptions need to be included in the migration budget?
If Central is part of the target management architecture, subscription type, device category, feature requirements and term should be checked. HPE publishes Foundation and Advanced options, and capabilities vary by service and infrastructure type.
Should all legacy hardware be replaced in one maintenance window?
Usually not unless the topology makes a single event necessary. A pilot followed by phased site or floor cutovers reduces uncertainty and allows the runbook to improve from real deployment findings.
What information is needed for a meaningful migration quote?
At minimum, provide site count, current switch and AP models, quantities, key configurations or backups, port usage, PoE endpoints, uplinks, WAN/firewall dependencies, management platform, authentication systems, desired target state, cutover constraints and support expectations.
Decision recap
Choose by role, port density, PoE, uplink, resilience and scale—not by old model equivalence.
Validate optics, fibre, cabling, LACP, STP, routing, authentication and endpoint behaviour.
Confirm Central support, subscriptions, inventory, groups, sites and migration of operational workflows.
Stage, test, define rollback thresholds and prove the runbook before broad deployment.
What FourTeck needs for an accurate UAE migration assessment
Plan your HPE Aruba migration around business continuity, not guesswork
Share your current Aruba or HPE network inventory, locations and target outcomes. FourTeck can help turn the legacy estate into a practical migration scope covering platform selection, subscriptions, staging, cutover, testing and handover for UAE deployment.