Mobile Modernization: Architect Playbook

Strategies for Migrating to the Cloud

In the context of this playbook, we are using the term “migrating to the cloud” to encompass strategies for making existing on premises data and assets accessible to mobile apps, both in and beyond the office. This does not, however, mean that mobile modernization requires a wholesale migration of your legacy data sources into public or private clouds. Quite the opposite. In fact, it’s rare to find legacy systems that need to be completely modernized. Instead, we believe that a successful cloud migration is one that is piecemeal, value-based and Interface-driven.

  • Piecemeal
  • Data and core functionality should be moved to the cloud in the smallest units possible, as opposed to moving entire systems, databases, or even services.

  • Value-based
  • What moves to the cloud should be driven by the highest need and value, as opposed to a sequential list or backlog.

  • Interface-driven
  • In many cases, “migration” means leaving core data in place, while using the cloud to expose targeted interfaces to that data via RESTful APIs, Microservices and the like.

In this section, we’ll discuss some cloud migration strategies, first through how you architect data services and systems, then through securing cloud data access.


Move the smallest units of functionality


Move based on need, not sequential order


Use RESTful APIs & Microservices to keep core data in place

Data Architecture

When planning the data architecture for mobile modernization, you should start with a clear picture of the role your monolith systems play in the effort, before determining how to migrate, expose and extend these into the cloud.

Addressing Your “Monolith”

For mobile modernization, data architecture starts with identifying and putting a virtual boundary around your “monolith.” This is the collection of databases and systems of record that are essential to the apps you plan to mobilize. They could be custom-built systems or off-the-shelf systems for things like CRM, ERP, etc. No matter the source of the system, you should create an inventory of the systems that make up your monolith and the core data and required for your mobilization effort.

As we’ve said already, we do not recommend a modernization effort predicated on the wholesale migration of one or more monoliths to the cloud. Even if your intention is to eventually replace a monolithic system with a modern one, this should be planned out over time, using one or more of the approaches below.


Fig 2. Successful cloud migration strategies start with an inventory. It is possible to move parts of a monolith to the cloud and leave other parts unchanged while still gaining advantages the cloud has to offer.

API Design

The first step is to provide access to monolithic data via a modularized, RESTful API. Not only does this approach provide an interface to your monolith that adheres to modern data access standards and practices (as opposed to native-driver-centric approaches of the past), but creating a RESTful API provides a blank slate upon which to define a clear migration path for enterprise data and core functionality.

One aspect of this approach that you’ll need to plan for is how to facilitate the connection between the RESTful API and your monolithic systems. There are a few approaches to choose from:

  • BaaS + API Gateway
  • An approach that wraps your monolithic sources and exposes data via mappings from source data to targeted, mobile-friendly data sources. Often facilitated by a BaaS or mBaaS product, such as Kinvey. Caching for increased data access performance.

  • Store-and-Forward
  • An approach that insulates your monolith from direct access, while providing mobile access to core data. Requires sophisticated sync and conflict-resolution capabilities, especially in cases where mobile data is read-write.

  • Secure Data Pipeline
  • An approach that provides secure access to on-premises data sources behind your firewall. One example is the Progress Hybrid Data Pipeline (HDP), which provides self-hostable data connectivity.

The goal, ultimately, is to create a reusable API layer that can power the mobile apps of today and tomorrow, while minimizing potential disruptions to existing legacy apps. With the right mix of these techniques, the traditional risks of migrating to the cloud can be significantly reduced.


Fig 3. Using a secure data pipeline to expose existing data to the cloud makes it easy to build scalable, RESTful APIs for mobile clients without disrupting existing legacy apps, and avoids the pitfalls of connecting mobile clients directly to legacy systems.


Kinvey is a complete serverless cloud platform from Progress that powers mission-critical apps. It provides everything required to deliver a high-performance, secure and compliant backend for every mobile project.

Named a Leader in the Forrester

“Wave” for “Mobile Development Platforms,” Kinvey specializes in helping development teams get to market over 75% faster.

If you’re trying to mobilize legacy systems or reuse existing auth providers, start with Kinvey. Kinvey can be run on any cloud, but unlike AWS, Azure or Google Cloud, which provide a “bag of parts” that development teams must assemble and maintain, Kinvey provides a seamless, integrated platform focused on compliance and productivity.

Learn more

Service Modularization & Granularity

Once you’ve identified one or more data access approaches for your API, you’ll want to consider how to define the surface of your API. When creating a secure API for your effort, granularity is key. Because of the unique constraints of modern mobile applications (networks, device data plans, etc) it’s rarely the case that your core data and services will map one-to-one to what’s needed on mobile.

Often, you’ll need to decompose a single service into multiple services to ensure that mobile devices are only pulling data needed for an app over a network. In many other cases, you may want to combine multiple services into a single API endpoint that provides a mobile-friendly payload. Very often, you’ll use both of these approaches, together.


Fig 4. Use microservices, serverless functions and aggregate web services tactically. Rarely will a monolith become "all serverless" or "all microservices." Migrating slices of functionality to these new paradigms is often the best balance between maximizing cloud performance and minimizing risk as you transition.

The table below highlights a few of the common service modularization approaches for you to consider.

Approach What it is
Service Aggregation & Orchestration Composing existing or related services into mobile- friendly APIs. Meant to minimize network calls and traffic in mobile apps by “normalizing” certain types of data. One example could be an Order API that pulls order and customer details from multiple monolith sources and combines these into a single payload.
Microservices Decomposition of services into small, targeted units. May be shared, or specific to a single application or use. Driven by the needs of the app or apps.
Serverless Event driven units of business logic or functionality as shared cloud services. Examples could be a unique email verification service or a CRM customer lookup services. Meant to be highly scalable and reduce operational costs compared to “always on” cloud services.

Table 5. Approaches for managing service granularity

Save this e-book for later
Would you like a free consulting session?

Want to learn more about mobility solutions?