Moving to ServiceNow Mobile Experience: Migration Considerations

Assessing Current Mobile and Web Application Landscape

Mobile Experience provides native mobile apps for iOS and Android. Before migrating, assess what mobile capabilities currently exist. Do you have mobile-responsive web applications, native apps built by a third party, or no mobile presence at all? Understanding current mobile usage helps define what capabilities are most important in the new mobile app. If your current mobile access is via responsive web, users expect better performance and features in a native app. If you have no mobile presence, implementation educates teams about mobile-first workflow benefits.

Survey users about mobile needs. Which ServiceNow modules do they access on mobile (incident management, request fulfillment, time tracking)? Which tasks must work offline (field service, asset management)? What devices and operating systems are in use? This data informs design priorities and helps focus initial mobile app development on highest-value use cases.

Workflow Redesign for Mobile Context

Mobile workflows are not simply web workflows on a smaller screen. Mobile users have different contexts (working in the field, quick status checks, attention-constrained), different network conditions (cellular, intermittent), and different interaction patterns (touch instead of mouse). Redesign workflows for mobile: simplify forms (fewer fields visible per screen), use mobile-friendly controls (pickers instead of long dropdown lists), minimise data entry by defaulting values from device sensors or user profile.

Prioritise the most important user tasks for initial mobile app version. Service desk technicians need quick incident status updates and assignment changes. Finance approval staff need to review and approve expense reports on-the-go. Sales need to check deal status. Don’t try to mirror every web feature in mobile; focus on high-value, frequently-used features first. Expand mobile capabilities incrementally based on user feedback.

Offline Functionality and Synchronisation Strategy

Mobile experiences often operate in offline contexts where network is unavailable. Define which functionality must work offline: can users view cached incident details offline but must be online to update? Can they complete small changes offline with sync when connectivity returns? Full offline capability with conflict resolution when data changes in ServiceNow while offline adds significant complexity. Balance offline capability with implementation cost: not every use case requires full offline support.

Decide synchronisation strategy: continuous sync (real-time, uses battery and bandwidth), periodic sync (hourly or on-demand), or event-triggered sync (sync when user performs an action). User expectations and business criticality drive this decision. For financial data, sync should be frequent; for reference data that changes rarely, less frequent sync suffices.

Cross-Device and Responsive Design Considerations

Users access mobile apps on varied devices: phones (various sizes), tablets, and even wearables in some cases. Design must work across this range. Responsive design adapts layouts to screen size; adaptive design creates different experiences for different form factors. Define minimum screen sizes to support (e.g., 4″ phone minimum, 10″ tablet). Test on representative devices and screen sizes; don’t assume your design works on all devices without testing.

Data Usage and Performance on Cellular Networks

Mobile apps operate over cellular data, which is slower and more expensive than WiFi. Minimise data payload: compress images, paginate lists to load on-demand, avoid loading unnecessary data. Design for intermittent connectivity: show loading indicators, queue actions when offline, handle timeouts gracefully. Performance degradation on cellular is expected; make it feel responsive anyway through good UX design (show feedback immediately, load data in background).

Testing on Real Devices and Network Conditions

Emulators are convenient but don’t accurately reflect real device performance. Test on physical devices (at minimum an iPhone and Android phone). Test on real networks (cellular and WiFi) with realistic connection quality. Use network throttling tools to simulate slow networks. Test battery impact: does your app drain battery quickly? Does intensive background sync cause issues? These characteristics only manifest on real devices under real conditions.

Plan for device management complexity: how will you manage app distribution, ensure apps are updated across all devices, handle app configuration changes? Mobile device management (MDM) platforms can automate these tasks but add licensing cost. Evaluate MDM necessity based on device count and management requirements.

User Adoption and Training Strategy

Mobile app adoption depends on user experience quality and training. Users comparing Mobile Experience to third-party consumer apps have high expectations—apps must be intuitive and responsive. Poor adoption can occur if the mobile app is harder to use than workarounds users have developed (email, spreadsheets). Plan training to show users where to find features and how to accomplish tasks in the mobile app. Highlight advantages: faster than web, works offline, uses location features, notifications push updates to users proactively.

Moving mobile users across without losing their saved work or their links

Changing the mobile tool a workforce uses is less about the new app than about what users have built around the old one. They have home screen icons, saved bookmarks, notification settings and sometimes drafts that exist only on their phone. A migration that ignores those details can look successful on the project plan and still fail on the first working morning, when a shift cannot find its app or a supervisor’s alerts stop arriving. The device-side cutover is covered here, aimed at the project lead and the service desk lead who will run the switch, on the assumption that the functional design is settled.

Inventory what lives on the old device

Before the cutover date, list what each user keeps on their phone that depends on the old tool. Typical items include the home screen shortcut, saved links in notes or messages, the offline cache, the push registration and local settings such as default filters. Some items can be carried over and some should be deliberately dropped. The inventory tells you which messages to write, drawing on the adoption and training plan, and which support articles to prepare.

An ordered cutover for one user group

1. Send a short notice well before the switch, naming the new app, the date and the one thing the user must do beforehand.
2. Ask supervisors to confirm that no open draft or in-progress job is held only on a phone, and to record any that are.
3. Enable the new app for the group and disable the old tool’s sign-in for the same group on the same day, so no user can work in both.
4. Check the first push alert and the first record open on one handset from each device family, and log the results.
5. Keep the old tool readable but not writable for a window agreed in advance, so users can still look up what they did before the switch.

Where device cutovers usually go wrong

The first failure is a group switched over on a Friday with no one on the service desk who has used the new app. The second is a supervisor receiving alerts from both tools for some time, because the old registration was never retired and both kept firing. The third is a user who discovers that a draft has vanished, because the old tool was removed before drafts were checked. A dated checklist with a named sign-off person prevents all three.

Signs the cutover has worked

Users in the first group can open the app, see their assignments and complete one task without help from the project team. The service desk handles questions about the new icon rather than about lost data. The old tool’s sign-in count falls to zero for the group, and each supervisor’s alert volume returns to its usual level. If users keep asking where a record went, the link and draft steps were skipped, and the next group should wait until they are done.

When to keep the old tool running longer

Keep the old tool in place when a process depends on a feature the new app has not yet reached, or when a regulated record must be read from the old source for a period. Decide which users stay on the old tool, for which tasks, and when they move, in line with the implementation roadmap. A split that is written down is manageable; a split that happens by accident is where records go missing.

A rollback plan for the device side

Write the rollback steps before the first group moves. A rollback usually means re-enabling the old sign-in for the group, re-registering push tokens and telling users in one message which tool to open. Test the steps on a single pilot user, because a rollback that has never been run may not work when it is needed.

Frequently asked questions about moving mobile users

Can we move users without asking them to reinstall anything?

Only where the old and new apps are the same package, which is uncommon when a team is changing tools. Plan for a reinstall, and keep the instruction short enough for a user to complete alone in a few minutes.

What happens to the offline data users stored on the old device?

It should not be carried across. The new app should build its own cache from the server after sign-in. Confirm the clearing rule on the old tool before the switch, so no data is left on a phone that is about to be returned.

Should the old app come off the store on the day of the switch?

No. Keep it available until the last group has moved and the drafts check is complete, then remove it in a separate step with its own message to users.

How do we know when the old tool can be fully retired?

When its sign-in count has stayed at zero through the agreed window, no push registrations remain and no open record depends on it. Record those three checks in the decommission log before removal is approved.

Next step

For the functional side of the move, the mobile integration patterns guide covers how the new app connects to the rest of the platform.