Migrating from Earlier Releases

improve this page | report issue

Overview

IBM Mobile Foundation v8.0 introduces new concepts for application development and deployment, and some API changes. Learn about these changes to prepare and plan for the migration of your MobileFirst applications.

You can also use use this lab to guide you through the v7.1 to v8.0 migration.

You can choose one of the following approaches to migrate your apps to Mobile Foundation v8.0.

Approach 1

Follow the migration cook book to perform a full-fledged migration to Mobile Foundation v8.0. Post migration you will have an app that is fully compatible with all of Mobile Foundation v8.0 features and functions.

Review the Migration Cookbook.

Approach 2

Use the Mobile Foundation Migration Studio to do an in-place migration of MobileFirst Platform Foundation v7.1 projects. This approach retains the legacy hybrid structure of your app while embedding it with Mobile Foundation v8.0 SDKs enabling your apps to connect to a Mobile Foundation v8.0 instance.

Jump to

Why migrate to IBM MobileFirst Foundation 8.0

Reduce Effort, Skill and Time Required to Build Apps

  • Build apps faster, simpler and smarter with standard package managers (npm, CocoaPods, Gradle, NuGet) and Maven for Java Adapter build automation
  • New simpler, modular, and easier to plug-in MobileFirst SDKs
  • New and improved overall user experience including anticipating users’ next best action and providing guided help throughout for registering, configuring and deploying apps

Enhanced Automation, and New Dev and IT Self-Service

  • New Live Update feature to externalize and dynamically change app configurable information (Push Notifications, Authentication, Adapters, App behavior and workflow)
  • Completely rethought, radically simplified Console user experience for registering, deploying and managing apps
  • A new simpler app architecture that eliminates the need for Dev and IT interdependence
  • Improved problem determination with new crash analytics, configurable alerts, and root cause analysis
  • Improved Push Notifications services enables targeted, subscription-based notifications sent from web console

More Hybrid Cloud Deployment Options

  • One-click provision of MobileFirst Foundation development, testing, and fully scalable production environments on IBM Cloud Public
  • Integrated with IBM DevOps Services and Urban Code for building your deployment pipelines

Multi-channel API creation and management

  • Step up API Connect multichannel security with mobile specific security extensions (e.g. Step Up, Multifactor) for maximum protection, then enforce in the DMZ with IBM DataPower
  • Create and define API Connect-compatible Swagger REST APIs in Foundation v8 then Manage and Secure them in API Connect

Changes in the development and deployment process

For a quick hands-on experience of the development process with Mobile Foundation V8.0.0, you can review the Quick Start tutorials.

In this version of the product, you no longer create a project WAR file that needs to be installed in the application server that is running MobileFirst Server before you can upload your apps. Instead, MobileFirst Server is installed once, and you upload the server-side configuration of your apps, of the resource security, or of the push service to the server. You can modify the configuration of your apps with the MobileFirst Operations Console. You can also upload a new configuration file for your apps by using a command-line tool or the server REST API.

MobileFirst projects no longer exist. Instead, you develop your mobile app with the development environment of your choice. You develop the server-side of your application separately, in Java™ or in JavaScript. You can develop adapters with Apache Maven or a Maven enabled IDE such as Eclipse, IntelliJ, and others.

In previous versions, applications were deployed to the server by uploading a .wlapp file. The file contained data that described the application and for hybrid applications, the web resources. In v8.0, the .wlapp file is replaced by an application descriptor JSON file for registering an app to the server. For Cordova applications that use Direct Update, instead of uploading a new version of the .wlapp, you now upload a web resource archive to the server.

When you develop your app, you use the MobileFirst CLI for many tasks, such as registering an app to its target server or uploading its server-side configuration.

Discontinued features and replacement path

Mobile Foundation V8.0.0 is radically simplified compared to the previous version. As a result of this simplification, some features that were available in V7.1 are discontinued in v8.0.

For more information about discontinued features and replacement path, see Features that are discontinued in v8.0 and features that are not included in v8.0.

Migrating a Cordova or hybrid application

You start developing Cordova apps with the Apache Cordova command-line tool or with a Cordova enabled IDE such as Visual Studio Code, Eclipse, IntelliJ, and others.

Add support for the MobileFirst features by adding the MobileFirst plug-ins to your app. For more information about the differences between V7.1 Cordova or hybrid apps and V8.0 Cordova apps, see Comparison of Cordova apps developed with v8.0 versus v7.1 and before.

To migrate a Cordova or hybrid app, you need to

Note: The migration of push notification support requires client-side and server-side changes and is described later on in Migrating push notification support.

Migrating a native application

To migrate native application, you need to follow these steps:

  • For planning purpose, run the migration assistance tool on your existing project. Review the generated report and assess the effort required for migration.
  • Update your project to use the SDK from Mobile Foundation v8.0
  • Replace the client-side APIs that are discontinued or not in v8.0. The migration assistance tool can scan your code and generate reports of the APIs to replace.
  • Modify the call to client resources that use the classic security model. For example, use the WLResourceRequest API, instead of invokeProcedure, which is deprecated.

Note: The migration of push notification support requires client-side and server-side changes and is described later on in Migrating push notification support.

Migrating adapters and security

Starting with v8.0, adapters are Maven projects. The MobileFirst security framework is based on OAuth, security scopes, and security checks. Security scopes define the security requirements to access a resource. Security checks define how a security requirement is verified. Security checks are written as Java adapters. For a hands-on experience with adapters and security, see the tutorials for Creating Java and JavaScript Adapters and Authorization concepts.

MobileFirst Server operates only in session-independent mode and adapters should not store a state locally to a Java virtual machine (JVM).

You can externalize adapter properties to configure adapters for the context where they run, for example a test server or a production server. But the values of these properties are no longer included in a property file of a project WAR file. Instead, you define them from the MobileFirst Operations Console, or by using a command-line tool or the server REST API.

Migrating push notifications support

The event-source-based model is no longer supported. Instead, use tag-based notification. To learn more about migrating push notification for your client apps and your server-side components, see Migrating push notifications from event source-based notifications and Migration scenarios.

Starting with v8.0, you configure the push service on the server side. The push certificates are stored on the server. You can set them from the MobileFirst Operations Console or you can automate certificate uploads by using a command-line tool or the push service REST API. You can also send push notifications from the MobileFirst Operations Console.

The push service is protected by the OAuth security model. You must configure server-side components that use the push service REST API must be configured as confidential clients of MobileFirst Server.

Push notifications data migration tool

Also available is a migration tool for push notifications data. The migration tool helps in migrating MobileFirst Platform Foundation 7.1 push data (devices, user subscriptions, credentials & tags) to Mobile Foundation 8.0.

Learn more about the migration tool.

Changes in the server databases and in the server structure

MobileFirst Server enables changes to app security, connectivity and push without code change, app rebuild or redeployment. But these changes imply changes in the database schemas, the data stored in the database, and the installation process.

Because of these changes, Mobile Foundation does not include automated scripts to migrate your databases from earlier versions to V8.0.0 or to upgrade an existing server installation. To move new versions of your apps to V8.0.0, install a new server that you can run side by side with your previous server. Then, upgrade your apps and adapters to V8.0.0 and deploy them to the new server.

Storing mobile data in Cloudant

Storing mobile data in Cloudant with the IMFData framework or CloudantToolkit is no longer supported. For an alternative API, see Migrating apps storing mobile data in Cloudant with IMFData or Cloudant SDK.

Applying a fix pack to MobileFirst Server

Find out how to use the Server Configuration Tool to upgrade MobileFirst Server V8.0.0 to a fix pack or an interim fix. Alternatively, if you installed MobileFirst Server with Ant tasks, you can also use Ant tasks to apply the fix pack or interim fix.

To apply an interim fix or fix pack on MobileFirst Server, choose one of the following topics based on your initial installation method:

▲
Inclusive terminology note: The Mobile First Platform team is making changes to support the IBM® initiative to replace racially biased and other discriminatory language in our code and content with more inclusive language. While IBM values the use of inclusive language, terms that are outside of IBM's direct influence are sometimes required for the sake of maintaining user understanding. As other industry leaders join IBM in embracing the use of inclusive language, IBM will continue to update the documentation to reflect those changes.
Last modified on July 02, 2020