Network management transition planning
HPE Aruba Central Migration in Dubai, UAE
Move from an existing Aruba management environment to HPE Aruba Networking Central with a migration plan built around your actual sites, devices, configuration model, licenses, integrations and operating procedures. FourTeck helps businesses prepare the source environment, identify what can transition directly and what must be rebuilt, stage the change, validate production services and document the new operating model.
Start with the migration facts
A useful quotation begins with the current management platform, Aruba device inventory, software versions, number of sites, configuration method, subscription position, required integrations and change-window expectations.
Classic Central, AirWave and controller-based environments follow different transition paths.
Templates, alerts, reports, APIs and policies may need recreation or redesign.
Device families, versions, subscriptions and target features should be confirmed before change.
Monitoring, client access, routing, alerts and operational workflows need post-change checks.
Direct answer: what is HPE Aruba Central migration?
HPE Aruba Central migration is the controlled process of moving network management and operational workflows toward HPE Aruba Networking Central. Depending on the source environment, the work can include readiness assessment, site mapping, device onboarding or transition, configuration recreation, floor-plan handling, alert and report redesign, API updates, licensing review, testing and handover. Organisations with Aruba wireless, switching, gateway or multi-site infrastructure should consider it when they want a current Central operating model. Before proceeding, buyers should confirm the source platform, device support, software versions, licenses, site structure, dependencies, integrations, acceptable outage window and which configurations must be preserved or rebuilt.
What the migration service does
A Central migration project turns an existing network-management state into a defined target operating state. The work begins by identifying how the network is managed today: which devices are present, which software branches they run, how sites and groups are arranged, where configuration is stored, what licensing applies, which integrations call APIs, and which dashboards or reports the operations team depends on. That baseline is then compared with the capabilities and workflows available in the target Central environment.
The objective is not to force every historical setting into a new interface. A better migration preserves the business outcomes that matter while adapting policies and operations to the target platform. This may mean recreating selected alerts and reports, redesigning templates, changing API endpoints, preparing sites, reviewing authentication, validating firmware paths, adjusting device grouping or documenting new administrator procedures. The final scope should reflect the customer’s source environment rather than a generic checklist.
Who should consider it
The service is relevant to organisations that already operate Aruba infrastructure and want to modernise management without treating the change as a simple software upgrade. It can also suit IT teams consolidating multiple sites, moving from AirWave, transitioning Classic Central operational workflows, introducing ArubaOS 10 where appropriate, or bringing more wired, wireless and WAN visibility into Central.
It is especially useful when the environment contains multiple device families, custom templates, external monitoring, API automation, floor maps, business-critical WLANs, complex VLAN or role design, or strict change-control processes. Very small and simple environments may require a lighter engagement, while large distributed networks normally need inventory analysis, pilot sites, rollback planning and staged cutovers. FourTeck can help decide the appropriate level after reviewing the actual estate.
Business problems a planned Central migration helps address
Migration work is valuable when it removes uncertainty from a change that affects daily network operations. The following challenges commonly influence project design.
Unclear source inventory
A network may have access points, switches and gateways spread across sites with mixed software versions, varying ownership records and inconsistent naming. Migration discovery creates a reliable inventory and identifies devices or components that require special handling.
Configuration that cannot be copied directly
Existing templates, policies, alerts, reports and operational settings may not have a one-to-one destination. The project should classify each item as transferable, recreatable, replaceable, obsolete or dependent on a different target feature.
Risky all-at-once cutover
Moving many sites without a pilot can multiply troubleshooting variables. A staged approach tests assumptions on representative devices or locations, captures lessons and gives the team a repeatable procedure before broad migration.
Operational blind spots after change
A technically successful migration can still fail the operations team if alerts, reports, dashboards, floor plans or API-driven workflows are missing. Validation should include the day-two activities administrators use to support the business.
Licensing uncertainty
Device management and feature availability can depend on subscriptions, device type and current vendor rules. Licensing should be reviewed against the target design rather than assumed from the existing platform.
Automation dependencies
Scripts, monitoring systems and service-management tools may rely on existing APIs. A migration plan should identify integrations early, map required functions and schedule testing before production automation is redirected.
Core outcomes to plan for
A documented view of devices, sites, versions, licenses, configurations and integrations.
Clear decisions on sites, groups, configuration methods, administrator access and monitoring workflows.
Pilot, cutover, rollback and validation steps matched to business change windows.
Documentation covering the migrated state, exceptions, support path and routine operational tasks.
Service-fit matrix
| Business situation | Relevant assistance | Scope dependency |
|---|---|---|
| Classic Central operations are being moved to the current Central experience | Site readiness, floor-plan review, alert and report recreation, API transition planning and validation | Current tenant state, sites, device support, configuration method and features in use |
| AirWave is being retired or reduced | Inventory review, destination design, migration method assessment, licensing review and operational handover | AirWave version, managed devices, topology, historical data needs and target Central deployment |
| AOS 8 wireless environment is being modernised | Readiness review, target architecture, configuration translation planning, pilot and staged cutover | Controller role, AP models, firmware path, feature use, tunnelling design and business tolerance for change |
| Multi-site network lacks a consistent operating model | Site and group design, naming, administrator scope, monitoring standards and change-control alignment | Organisation structure, delegated IT roles, site count and desired standardisation |
| External tools depend on Central APIs or alerts | Integration inventory, endpoint mapping, credential and permission review, test plan and cutover sequencing | Applications, scripts, API functions, authentication method and vendor-supported equivalents |
Migration service information
The exact statement of work should be built after discovery. The table below shows the areas that typically need to be discussed; it does not imply that every activity is automatically included in every quotation.
| Topic | HPE Aruba Central Migration Dubai |
|---|---|
| Page type | Migration, configuration and professional-services guidance |
| Main purpose | Plan and coordinate a controlled transition to HPE Aruba Networking Central while preserving required business operations and rebuilding workflows where direct migration is unavailable. |
| Suitable for | Businesses, campuses, hospitality environments, healthcare organisations, education networks, warehouses, distributed offices and enterprises operating compatible Aruba infrastructure. |
| Typical source environments | Classic Central, AirWave, selected controller-based Aruba WLAN environments, Instant deployments and other supported Aruba management states. Exact applicability must be confirmed. |
| Assessment support | Inventory, software versions, sites, groups, templates, reports, alerts, floor plans, authentication, licensing and integration review. |
| Planning support | Target-state mapping, migration sequence, pilot selection, change window, rollback planning, stakeholder roles and validation criteria. |
| Configuration support | Scope dependent. May include site/group setup, supported device onboarding, recreation of required settings and operational workflow configuration. |
| Integration support | Review of APIs, monitoring, identity, ticketing or automation dependencies where they form part of the agreed project. |
| Licensing guidance | Subscription and feature requirements should be confirmed against the device inventory and target design. License availability and terms are vendor-policy dependent. |
| Testing and handover | Validation checklist, exception record, administrator handover, migration documentation and agreed support follow-up. |
| Customer inputs required | Device export or inventory, current diagrams, platform access, license information, integration list, change constraints, business-critical services and technical contacts. |
| Remote or on-site coordination | Project dependent and agreed in the quotation. |
| Availability guidance | Contact FourTeck to confirm current UAE scheduling, licensing, product dependencies and professional-services scope. |
| Important note | Migration behaviour depends on the source and target platform state. No assumption should be made that templates, policies, reports, alerts, floor plans or integrations transfer automatically. |
Dependencies to confirm before any production migration
The migration method is source dependent. HPE’s current documentation distinguishes between operational transition from Classic Central, migration of floor plans, manual recreation of certain settings, AirWave migration scenarios, and ArubaOS transition workflows. Because of that, a proposal should identify exactly what is being moved and why. Device onboarding, configuration, monitoring, reporting, authentication and API transition may be separate workstreams rather than one single action.
Confirm the Central tenant and region, administrator access, current subscriptions, supported hardware, firmware compatibility, existing site assignments, configuration groups or templates, role-based access, external authentication, custom alerts, scheduled reports, floor plans, automation scripts, API clients, logging destinations, WAN or VPN dependencies, and any features that the operations team considers business critical. If the migration involves AOS 8 to AOS 10, the target wireless architecture and feature equivalence require their own assessment. If AirWave is involved, the AirWave version and the required destination must be reviewed before a method is selected.
A practical migration journey
Discovery and evidence collection
Capture the source platform, sites, device inventory, serial and model information where available, software versions, groups, templates, SSIDs, VLAN dependencies, gateway roles, integrations, reports, alerts, floor plans, administrative roles and subscriptions. The purpose is to replace assumptions with evidence. For larger estates, the inventory should be reconciled against live management data and current diagrams so that orphaned or retired objects do not shape the new design.
Readiness and gap assessment
Map the existing estate to the target Central capabilities. Identify supported devices, firmware requirements, license dependencies, functions that will transition, objects that require recreation and features that may need redesign. This stage should also review how sites will be represented because site assignment is important to monitoring and day-two operations in the current Central experience.
Target design and migration runbook
Define the target organisation, site and group structure, naming standards, configuration method, administrator model, alert and report requirements, integration handling, test cases and rollback approach. The runbook should sequence each action and identify who performs it, who approves it, what success looks like and which evidence should be captured.
Pilot migration
Choose a representative but controllable site or device group. The pilot should exercise the same configuration and operational dependencies expected in production: authentication, client access, switch management, gateway or tunnel functions where relevant, monitoring, alerts, reports and integration calls. Document unexpected behaviour and update the runbook before wider rollout.
Staged production transition
Move the approved scope in planned waves rather than treating the estate as one undifferentiated change. Wave design can be based on site type, geography, device family, business criticality or technical dependency. Each wave should have a start condition, validation window and decision point before the next wave proceeds.
Operational validation and handover
Check device visibility, site assignment, configuration state, client connectivity, routing or tunnelling where applicable, alerts, reporting, floor plans, administrator access, integrations and expected monitoring data. Capture exceptions and final ownership. Handover should help the IT team operate the new environment, not simply confirm that devices appeared in a dashboard.
Capability focus: preserving operational visibility
Network migrations are often judged by connectivity alone, but day-two visibility is equally important. Administrators may rely on site dashboards, health views, topology, alerts, scheduled reports, floor maps and API-fed tools to understand what users are experiencing. When the target platform uses a different operational model, these functions should be reviewed deliberately. A custom alert in Classic Central, for example, may need to be recreated because the current Central alerting framework is different. Reports can also require recreation rather than automatic carry-over.
The migration scope should therefore identify the operational views that matter to the service desk and network team. For each one, define the target equivalent, required permissions, data source, severity or threshold logic, recipient group and validation method. This prevents a common problem: the infrastructure is technically migrated, but the team loses the monitoring habits it uses to detect issues. FourTeck can include this operational mapping in the discovery and test plan when visibility is part of the agreed requirement.
Capability focus: converting configuration into a maintainable target model
A migration can be an opportunity to reduce years of configuration drift. Existing groups and templates may contain obsolete settings, local exceptions, temporary workarounds and naming conventions that no longer reflect the organisation. Copying them blindly would reproduce that complexity. Where the target Central workflow requires manual configuration or a different object model, the design should separate requirements from historical syntax.
The team can classify settings as mandatory baseline, site-specific variation, device-specific exception or retired configuration. Then the target structure can be built around repeatable standards. This is particularly important in wireless transitions that also involve ArubaOS architecture changes, where policy and configuration objects may not map directly. The aim is not to promise perfect equivalence; it is to document which business outcomes are required and validate that the target design supports them before broad cutover.
Capability focus: keeping integrations working
Modern network management rarely operates alone. Central data may feed monitoring tools, dashboards, scripts, ticketing platforms, identity workflows or reporting systems. During a platform transition, these dependencies can fail quietly if API endpoints, authentication, response formats or permission models change. The migration discovery should therefore ask which applications call the existing management platform and what they do with the data.
For each integration, identify the business owner, function, authentication method, schedule, critical endpoints and test case. Current HPE migration guidance specifically calls out API transition for Classic Central monitoring, reporting and troubleshooting workflows. Code changes and testing may be required. FourTeck can coordinate an integration workstream where it is included in scope, but application development, third-party licensing or vendor-specific changes should be defined separately rather than assumed to be included.
Ideal business environments and use cases
Distributed offices
Organisations with many branches can use a migration project to standardise site naming, monitoring expectations, administrator roles and repeatable configuration patterns before expanding Central operations.
Campus and education
Large wireless and switching estates often depend on floor plans, user onboarding, alerts, reports and multiple administrator teams. A staged migration can protect teaching, examinations and operational windows.
Hospitality and guest networks
Hotels and venues may require careful treatment of guest access, authentication, roaming, floor coverage, WAN connectivity and 24-hour operations. Pilot and rollback design should reflect occupancy and service windows.
Warehouses and logistics
Wireless devices may support scanners, voice, inventory and operational applications. Migration validation should therefore include application reachability, roaming behaviour and site-specific network dependencies.
Healthcare and business-critical sites
Change plans should prioritise stakeholder approval, access-control dependencies, monitoring, rollback readiness and evidence collection. The migration must be scheduled around the organisation’s service obligations.
Network operations modernisation
IT teams moving away from legacy management can use the project to define a clearer day-two operating model covering dashboards, alerts, reports, API automation, administrative scope and change control.
Integration and operational considerations
Before a cutover, document identity services, RADIUS or TACACS dependencies where used, DHCP and DNS reachability, VLAN and routing assumptions, gateway or tunnel roles, internet access required by managed devices, logging and monitoring destinations, management access controls, API applications and maintenance processes. A change in management platform should not accidentally change network behaviour unless that change is part of the approved target design.
Operational teams should also decide how incidents will be handled during the migration period. If Classic Central and the current Central experience coexist for part of the transition, administrators need clear instructions about which interface is authoritative for each task. Ownership of firmware changes, configuration edits and troubleshooting should be explicit to reduce conflicting changes during the project.
Questions buyers should resolve before ordering
What is the exact source management platform? Which devices and software versions are in scope? Are all devices assigned to meaningful sites? Which configurations are template based and which are UI or device specific? What reports, alerts and API integrations must continue after the migration? Does the project also include an ArubaOS transition? Which subscriptions are active, and which features are required in the target environment? What is the acceptable disruption window? Which site can serve as a pilot? Who will approve the target design and each migration wave?
Answering these questions early produces a more accurate statement of work and helps avoid a quote built only on device count. Two networks with the same number of access points can require very different migration effort if one has simple standard configuration and the other has many templates, integrations, floor maps and site-specific exceptions.
Procurement and evaluation checklist
✓ Confirm the exact source management platform and tenant.
✓ Export or document the in-scope device inventory and quantities.
✓ Record device families, current software and target-version requirements.
✓ Identify Central subscriptions, renewal dates and required feature tiers.
✓ List sites, groups, templates, SSIDs, VLANs and policy dependencies.
✓ Identify custom alerts, scheduled reports and floor plans that matter.
✓ Document API clients, monitoring platforms and external integrations.
✓ Define the pilot location and acceptable maintenance window.
✓ Agree whether installation or on-site engineering is required.
✓ Define rollback criteria and post-change validation tests.
✓ Decide the documentation and knowledge-transfer requirement.
✓ Confirm regional scheduling and commercial scope with FourTeck.
How FourTeck can structure the engagement
FourTeck can support the migration as a scoped professional-services engagement rather than a generic fixed package. The first step is requirement clarification. The customer shares the source environment, site and device counts, software information, current management method, known integrations, licensing position and desired outcome. FourTeck can then identify which parts require assessment before a firm implementation scope is possible.
For straightforward environments, the engagement may focus on readiness, migration execution and validation. More complex networks may benefit from a discovery workshop, target design, pilot, staged migration waves, configuration reconstruction, operational workflow setup and post-migration documentation. Where new licenses, subscriptions, access points, switches, gateways or support services are required, those items can be quoted separately so procurement can distinguish platform costs from professional-services effort.
Customers that need broader infrastructure assistance can review FourTeck’s technology services and network and security products. For a project conversation, use the FourTeck contact page and include the current platform, device quantities and desired completion window. This gives the technical team enough context to recommend the next step without assuming that every migration follows the same method.
UAE availability and support guidance
Contact FourTeck to confirm current UAE professional-services availability, licensing dependencies, project scheduling and any hardware required as part of the migration. The implementation calendar may depend on the number of sites, device count, source platform, access permissions, change windows, customer approvals and whether work is remote, on-site or mixed. If installation, configuration, migration assistance or knowledge transfer is required, include that scope in the quotation request. Product subscriptions, support entitlements and vendor lead times should be checked against the final bill of materials rather than assumed from a previous environment.
Dubai, Abu Dhabi, Sharjah and Ajman coverage
FourTeck can coordinate HPE Aruba Central migration discussions for organisations operating across Dubai, Abu Dhabi, Sharjah and Ajman as part of one UAE project plan. Multi-location customers should provide a site list, device counts, source management details, local access constraints and preferred change windows so the migration can be grouped into sensible waves. The technical scope may differ by site: a headquarters with gateways, switching, wireless and integrations can require more preparation than a small branch with a standard access-point profile. Remote and on-site activities should be agreed in advance, including who provides rack or console access, local hands, change approval, testing and business sign-off. Regional scheduling remains dependent on the confirmed statement of work.
GCC Availability
For organisations planning a Central migration across the GCC, FourTeck can help review the requirement before procurement or change scheduling. A regional project may involve the United Arab Emirates, Saudi Arabia, Kuwait, Qatar, Bahrain or Oman, but the migration method should still be designed around the actual source environment at each site. Customers can share the destination country, current platform, in-scope devices, quantities, license or subscription details, change windows and whether local implementation support is expected. FourTeck can assist with requirement review, model or license selection where new items are required, quotation coordination, configuration scope and regional project planning. Availability, subscription rules, vendor lead times, delivery schedules, service visits and implementation scope can vary by country, model, quantity and project requirement. For Kuwait-related infrastructure coordination, buyers may also review FourTeck Kuwait. Confirm the exact destination and timeline before treating any schedule as committed.
Africa Availability
FourTeck can also assist organisations evaluating HPE Aruba Networking Central migration projects in Africa, including multi-site and cross-border requirements. The useful starting point is not a broad country list but a clear technical baseline: destination country, existing management platform, device models and quantities, software versions, license position, site count, target Central approach, planned schedule and any need for installation or post-migration support. Depending on the project, FourTeck can help evaluate licenses, accessories, subscriptions, configuration scope, renewal requirements and procurement planning. Fulfilment can vary according to destination, equipment model, license region, power or regulatory requirements, shipping arrangements, vendor lead time, local access and installation scope. Customers in East Africa can review FourTeck resources for Kenya technology projects, while broader requirements can be discussed through FourTeck Africa. No local inventory, immediate shipment, customs outcome or on-site coverage should be assumed until the requirement is confirmed.
Related options to consider with a migration
Central licensing review
Confirm subscription coverage and required feature level for every managed device before scheduling migration waves.
AOS 8 to AOS 10 planning
Where wireless architecture is also changing, treat the operating-system transition as its own design and validation workstream.
AirWave transition assessment
Review AirWave version, managed devices, historical operational dependencies and the correct Central destination before choosing a migration method.
Wireless and switching refresh
If unsupported or aging devices are discovered, separate hardware refresh decisions from the management migration so procurement remains clear.
Post-migration support
Agree the handover period, issue ownership and escalation path if the operations team wants help after production waves are complete.
Why businesses contact FourTeck for Central migration planning
The practical value is in turning an uncertain change into a list of decisions that can be quoted, scheduled and tested. FourTeck can help clarify whether the requirement is a Classic Central operational transition, an AirWave migration, an ArubaOS modernisation, a device onboarding project, a licensing exercise or a combination of several workstreams. That distinction matters because each path has different dependencies.
FourTeck can also help build a bill of materials where subscriptions or replacement hardware are required, review compatibility information supplied by the customer, define configuration and installation scope, plan a pilot, coordinate change windows and document the validation criteria. If the project touches firewalls, WAN connectivity or broader network security, buyers can explore the FourTeck Dubai network-security portal for related services. The objective is to match the engagement to the customer’s real environment without claiming a fixed outcome before discovery is complete.
Decision guidance for real migration projects
What buyers are trying to understand before they commit
Can Classic Central simply be copied into the current Central?
Not as a general rule. Current HPE guidance describes migration as a mix of synchronized elements and manual work. Sites can synchronize, while configuration such as templates remains a manual process in documented transition scenarios. Custom alerts and scheduled reports also need to be recreated in the current framework. That means buyers should not price the project only by counting devices. The number and complexity of templates, alerts, reports, floor plans and operational exceptions can materially affect effort. A useful discovery exercise records which objects matter, who uses them and whether the target platform offers an equivalent or a better replacement.
What happens to sites and devices during transition?
Site design deserves early attention because the current Central operating model uses sites heavily for monitoring and operational scope. HPE documentation notes that devices without appropriate site assignments can be placed into an unmapped state during Classic Central transition. Buyers should review site names, physical locations and device membership before migration, especially if the old environment relied mostly on groups. This is also a good time to correct inconsistent naming and remove stale objects. A site structure should help operations staff understand where equipment is physically installed and should align with the way the organisation delegates responsibilities.
Will floor plans, alerts and reports come across automatically?
Different data types follow different processes. Current HPE migration guidance provides an account-level floor-plan migration workflow for eligible Classic Central environments, while alerts and reports are treated as settings that must be recreated in the current platform. Floor-plan migration itself has conditions and should be prepared carefully because the platform can treat unsupported or missing destination devices differently. Buyers should therefore create a simple data-retention matrix: floor plans, alert rules, report schedules, dashboards, audit needs and historical records. For each item, define whether it must migrate, be rebuilt, be archived outside Central or can be retired.
Does a Central migration also mean moving from AOS 8 to AOS 10?
Not necessarily. Central migration is a management-platform topic, while an AOS 8 to AOS 10 change can alter the wireless operating model and configuration structure. Some organisations undertake both changes as part of one modernisation programme, but the workstreams should be distinguished in the plan. If AOS 10 is part of the target, confirm AP and gateway support, current architecture, firmware path, role and policy requirements, tunnel design, authentication, guest access, redundancy expectations and feature dependencies. HPE itself offers professional services specifically around AOS 8 to AOS 10 migration, which underlines that this transition warrants design effort rather than being treated as a routine firmware update.
How should an AirWave migration be approached?
Start by identifying the exact AirWave version, managed device types, current use of VisualRF or other operational data, and the intended Central destination. HPE has documented migration methods for specific AirWave-to-Central On-Premises scenarios, while cloud migration requirements can differ. Do not assume that an archived procedure applies to a different Central deployment or software generation. A FourTeck assessment can help collect the evidence needed to determine the appropriate path, but the final migration method should be based on current vendor documentation that matches the customer’s source and destination.
What information produces a useful migration quotation?
Provide more than a device total. A stronger request includes the source platform and version, Central tenant details, number of sites, access points, switches and gateways, current firmware, configuration method, number of templates, use of floor maps, custom alerts and reports, API or third-party integrations, subscription position, desired target architecture, pilot preference, change windows, required on-site work and documentation expectations. This lets professional-services effort be separated from hardware or licensing costs. It also exposes unknowns that may need a discovery workshop before implementation can be priced accurately.
Buyers also ask whether migration can be completed without downtime. The correct answer depends on the source architecture, device types, firmware path and change being performed. Some management-plane activities may not interrupt client traffic, while software upgrades, controller or gateway changes, device reprovisioning or configuration transitions can affect service. The project should define expected impact for each wave and schedule it around business requirements rather than promising a zero-downtime outcome in advance.
Questions to settle before you schedule the cutover
Which Central experience is the target?
State the exact target tenant and management experience. The term “Aruba Central migration” can refer to several transitions, including Classic Central operational workflows, AirWave migration, or network architecture changes that also introduce newer Central capabilities. The target determines which HPE documentation and prerequisites apply.
Which configuration must be preserved exactly?
Separate business requirements from historical configuration syntax. SSIDs, VLANs, roles, routing, authentication and application dependencies may be critical, while unused templates or old exceptions may not be. This distinction reduces unnecessary reconstruction and makes validation measurable.
What must operations staff see on day one?
List the dashboards, alerts, scheduled reports, floor plans, client views, device health information and API-fed tools required immediately after cutover. Rebuilding these operational functions can be as important as moving device management because the support team depends on them for incident response.
What is the rollback decision?
Define specific failure conditions that trigger rollback or pause the next wave: loss of client authentication, device management failure, unexpected routing change, unavailable monitoring, integration failure or unacceptable user impact. The rollback plan should be tested conceptually before the window begins.
Who owns third-party integrations?
If scripts, monitoring software, ticketing or identity systems depend on existing Central APIs, define who can change and test them. FourTeck can coordinate the migration-side requirement when included in scope, but application owners may need to modify their own code or vendor connectors.
How will the new environment be handed over?
Agree on the required diagrams, inventory, configuration summary, exceptions list, administrator roles, operating notes and knowledge-transfer session. A migration is easier to support when the final state is documented for the people who will own it after the project team leaves.
The most efficient next step is usually a requirements discussion supported by an inventory export and a short description of the current management model. FourTeck can then advise whether the project can move directly to implementation planning or whether a deeper readiness assessment is needed first.
Frequently asked questions
What does HPE Aruba Central Migration in Dubai include?
Scope can include discovery, readiness review, target design, site preparation, license checks, migration planning, configuration recreation, device transition, floor-plan handling, alert and report setup, API transition, testing, documentation and handover. The exact activities depend on the source environment and agreed statement of work.
Can Classic Central configuration be migrated automatically?
Do not assume full automatic configuration migration. Current HPE guidance states that site information can synchronize in documented scenarios, while configuration such as templates remains a manual process. Custom alerts and reports also need recreation in the current framework.
Can existing floor plans be moved?
HPE documents account-level floor-plan migration from Classic Central for eligible environments, with prerequisites and limitations. The source account, permissions, site structure and current platform state should be checked before relying on that workflow.
Is AOS 8 to AOS 10 migration part of every Central project?
No. It is a separate architecture and software transition that may be included when required. If it is in scope, device support, firmware path, configuration and policy design, gateways, authentication, tunnelling and application dependencies should be assessed independently.
Can FourTeck help with AirWave migration?
FourTeck can review an AirWave-to-Central requirement and help determine the information needed for the correct migration path. The AirWave version, target Central deployment, device estate and required data should be confirmed because vendor procedures differ by scenario and software generation.
Are Aruba Central licenses included in the migration service?
Not unless the quotation explicitly includes them. Subscription needs are device and feature dependent. FourTeck can help review licensing requirements and quote licenses separately where required.
Will the migration require downtime?
It depends on the exact work. Management-only preparation can differ from firmware upgrades, controller or gateway changes, device reprovisioning and configuration cutovers. The project plan should state expected impact by migration wave and include rollback criteria.
What information is needed for a quotation?
Share the source platform, site count, device quantities and families, software versions, template use, floor plans, custom alerts and reports, APIs or integrations, active subscriptions, desired target state, change windows, on-site requirements and documentation expectations.
Can migration be completed remotely?
Some discovery, configuration and validation activities may be suitable for remote delivery, while other tasks can require local access or customer hands. Remote and on-site scope should be agreed after the environment and change plan are understood.
How do we request HPE Aruba Central migration support from FourTeck?
Use the FourTeck contact page and provide a short description of the existing management platform, device estate, number of sites and desired project timeline. FourTeck can then advise what discovery information is needed before preparing a scope and quotation.
Plan the migration around your actual network
Send FourTeck the source platform, device and site counts, software versions, license position, integrations and preferred change window. The team can help determine whether you need a readiness assessment, a pilot, a staged migration, configuration reconstruction, licensing support or a combined project.