Migrating from MobileIron to AirWatch: Key Considerations

Moving an enterprise mobility estate from MobileIron to AirWatch involves more than transferring administrative settings. AirWatch, now associated with VMware, gives organisations a unified platform for device enrolment, application access, security policy and endpoint support. It is particularly relevant to Australian businesses managing corporate smartphones, tablets and personally owned devices across distributed workforces.

The transition can simplify management, consolidate identity services and reduce reliance on fragmented tools. However, a successful migration depends on careful preparation, accurate feature mapping and clear ownership of every stage. Devices, applications, certificates, compliance rules and user workflows must continue operating while the underlying platform changes.

Australian organisations also need to account for the Privacy Act 1988, applicable state and territory privacy requirements, hybrid work patterns and support across widely separated time zones. This guide explains the practical decisions that should shape a MobileIron-to-AirWatch migration, from technical discovery through to pilot testing and final cutover.

Assess the current MobileIron estate

Begin with a complete inventory rather than a direct platform-to-platform comparison. Record device counts, operating-system versions, ownership models, assigned applications, compliance profiles, VPN configurations, certificates, administrative roles and connected systems such as Apple Business Manager, Google Workspace and corporate identity providers. Export existing policies where possible and label each one by function, business owner and priority.

Define what the migration is intended to achieve. Some organisations want consolidated device management, while others are replacing costly support contracts, improving application security or simplifying access to email and line-of-business systems. Separate mandatory requirements from features that merely appear in the current MobileIron console. This prevents legacy complexity from being copied into AirWatch without a clear operational benefit.

Include user communities and regional requirements in the assessment. Field workers in mining, logistics and healthcare may depend on offline access, shared devices or particular diagnostic tools, while office teams in Sydney, Melbourne and Brisbane may have different application and data-protection needs. Device retirement dates, pending hardware refreshes and planned application changes should also influence the migration sequence.

Map AirWatch architecture and feature gaps

AirWatch services may be delivered through VMware Workspace ONE, so buyers should confirm precisely which tenancy, console and licensing model they are purchasing. A proof of concept should use the intended production identity configuration, not a simplified demonstration environment. Document federation with Microsoft Entra ID, Okta, VMware Identity Services or an on-premises directory, as well as certificate authorities, service accounts and API integrations.

Map MobileIron policies to their AirWatch equivalents by business outcome. Compare enrolment methods, compliance checks, app delivery, containerisation, per-app VPN, SSO, conditional access, remote support and administrative delegation. Some rules may translate directly, while others may require redesign or an alternative workflow. Scripts and custom integrations deserve particular scrutiny because they can create hidden dependencies and require separate testing.

Create an integration register covering email, collaboration tools, endpoint detection, ticketing, SIEM, software distribution and enterprise app stores. Record the data exchanged, authentication method, owner and migration action for each connection. Local applications built for government, education, healthcare or transport teams may rely on MobileIron-specific APIs or managed application configurations and should be validated with their developers before deployment.

Design the migration sequence and data transfer

Use a phased approach with defined gates between each stage. Start with a representative pilot that includes corporate-owned and personally owned devices, the principal identity provider, business-critical applications and both major mobile operating systems. A pilot in one location or business unit can reveal configuration and adoption problems without exposing the entire workforce to disruption.

Plan how devices will enter AirWatch before changing their management owner. Depending on platform support and device condition, options may include direct reassignment, re-enrolment, migration tooling or a temporary coexistence arrangement. Corporate devices can often be prepared through automated enrolment, whereas BYOD re-enrolment usually requires more user communication and may lead to different data-retention decisions.

Protect the technical cutover by renewing certificates and verifying notification credentials before they expire. Apple Push Notification service and Firebase Cloud Messaging credentials, SAML signing certificates, VPN profiles and certificate enrolment settings must remain valid throughout the process. Keep tested rollback procedures and administrative access outside the affected tenant. For distributed teams, schedule work around Australian business hours and remember that Perth operates two hours behind the eastern states.

Protect identity, data and regulatory alignment

Treat identity as the foundation of the AirWatch environment. Test conditional access, role changes, joiner, mover and leaver workflows, multi-factor authentication and device compliance decisions. Confirm that a failed network connection, unavailable compliance service or stale directory attribute produces the intended response rather than locking users out of essential systems.

Review how records, credentials and application data are handled during migration and on departure. The Privacy Act 1988 and Australian Privacy Principles may apply to many private-sector organisations, while health services, financial organisations and government agencies may also be covered by state, territory or sector-specific rules. Map data flows, retention periods, deletion processes and vendor access, and include these obligations in contractual and audit requirements.

Validate the target security model against the Australian Signals Directorate’s Essential Eight where appropriate. This framework is mandatory for Commonwealth entities and is widely used as a benchmark elsewhere. Test application allow-listing, patching, MFA, restricted administrative privileges, logging, backups and incident response. AirWatch should improve the organisation’s security posture rather than merely reproduce existing controls with different labels.

Prepare people, devices and operating processes

Create a role-based training plan for mobility administrators, service-desk staff, security teams and application owners. Provide practical exercises covering enrolment, policy troubleshooting, application assignment and recovery procedures. Local documentation should use Australian English, familiar terminology and the organisation’s usual escalation paths. A concise guide for employees also reduces errors during re-enrolment.

Address BYOD carefully. Employees need to understand what AirWatch can access, which information is collected, how company data is separated and what happens when they leave. Application publishers may need updated managed configuration files or new APIs, while remote wipe and work-profile behaviours should be tested on common Samsung, Google and Apple devices. Devices that cannot meet the required security standard need a clear replacement path.

Redesign support procedures around the new console and escalation model. Update knowledge-base articles, diagnostic scripts, device-replacement workflows and procurement checklists. Australian organisations often coordinate technicians and business owners across Sydney, Melbourne, Brisbane, Perth and regional sites, so support ownership and after-hours arrangements should be explicit. Local expectations for responsive service and direct communication make early escalation channels especially valuable.

Control costs and prove the target state

Build a total-cost model covering licences, implementation labour, identity integration, certificate services, training, application changes, support and the decommissioning of MobileIron. Request an Australian business quote that clarifies whether prices include GST and compare subscription levels against realistic device and user numbers. Include internal productivity during re-enrolment and any legacy contract exit fees rather than focusing only on licence pricing.

Use the fully functional 30-day AirWatch free trial to test the highest-risk workflows. Measure enrolment time, policy accuracy, application reliability, help-desk demand, administrator effort and user satisfaction. Trial duration may not accommodate every device refresh, but it can still expose permission problems, integration failures and unnecessary configuration complexity. Review package comparisons to align features with actual requirements, and consult customer stories for practical deployment experience.

Set formal approval criteria before the production cutover. These should include successful identity tests, device compliance, application readiness, security review, support readiness and an agreed rollback plan. Establish ownership for post-migration optimisation so that the target state continues improving after launch. This prevents the AirWatch implementation from becoming another collection of policies nobody regularly reviews.

Assess your migration requirements with a structured AirWatch proof of concept, use the fully functional 30-day free trial to validate critical workflows, and review package comparisons and customer stories before contacting sales. An Australian quote and migration consultation will help define licensing, implementation effort and a realistic transition schedule for your organisation.