Migrating iOS Native Custom Applications

Understand the strategies and steps to follow when you transition applications to the current release.

Migration Strategies

Your strategy for transitioning MBS-based iOS applications to the current release depends on your current installation configuration, upgrade plans, and the data model changes in the application to be transitioned. Follow the guidance in the scenario that fits your installation configuration and upgrade plan.

Scenario 1
  • Current Installation - 2.1 ESD #2 or earlier MBS client application on 2.1 ESD #2 or earlier Unwired Server
  • Upgrade Plan - Upgrade only Unwired Server to the current version, and maintain the existing MBS client application

Your MBS client application should continue to work without error after server upgrade, though some RBS features will not be available for your MBS client application. See Maintaining MBS Client Applications

Scenario 2
  • Current Installation - 2.1 ESD #2 or earlier MBS client application on 2.1 ESD #2 or earlier Unwired Server
  • Upgrade Plan - Upgrade both Unwired Server and client application to the current version. Upgrade the client application to an RBS-based application.
  • No Data Model Changes in the application
Recommended Steps:
  1. Instruct application users to submit all pending data to the Unwired Server using the existing MBS client application before you migrate to the new RBS application, and coordinate the upgrade. This is an important step as it will ensure that application users do not lose any modified data during your migration. With MBS, once submitPending is invoked, the modified data is wrapped as an operation replay message to be sent as soon as connectivity with the server is available. If the application user does not invoke submitPending prior to migration, all of their data changes will be lost once migration begins. For this reason, you will need to instruct the application users to use the appropriate UI control exposed by the MBS application to invoke submitPending before you migrate the application.
  2. Follow the steps included in Transitioning MBS Client Applications to convert the MBS application to the new RBS application, creating a different application name for the new RBS application on the device. Include explicit screens/message popups within the application to alert the application user to follow these steps:
    1. Submit all pending data from the MBS client application to the Unwired Server.
    2. Confirm that the pending data has been submitted, delete the MBS application, and then begin using the new RBS application.
      Note: Once the application user acknowledges and confirms that pending data from the old application has been submitted, do not display the popup/screen messages again.
    3. Subscribe and synchronize the new RBS application with the upgraded Unwired Server.
Note: You need to use a different Application Name to avoid an accidental update of the MBS application before the application user has a chance to submit their changes. However, you can use the same Application ID for both the new RBS application and for the existing MBS application.
For more in depth steps to transition your MBS client application to RBS, see Transitioning MBS Client Applications
Scenario 3
  • Current Installation - 2.1 ESD #2 or earlier MBS client application on 2.1 ESD #2 or earlier Unwired Server
  • Upgrade Plan - Upgrade both Unwired Server and client application to the current version. Upgrade the client application to an RBS-based application.
  • Data Model Changes in the application or MBO project
Recommended Steps:
  1. Instruct application users to submit all pending data to the Unwired Server using the existing MBS application before you migrate to the new RBS-based application, and coordinate the upgrade. This is an important step as it will ensure that application users do not lose any modified data during your migration. With MBS, once submitPending is invoked, the modified data is wrapped as an operation replay message to be sent as soon as connectivity with the server is available. If the application user does not invoke submitPending prior to migration, all of their data changes will be lost once migration begins. For this reason, you will need to instruct the application users to use the appropriate UI control exposed by the MBS application to invoke submitPending before you migrate the application.
  2. Deploy the new package with data model changes to the server using a new Application ID. Create a new application connection in the Sybase® Control Center.
  3. Follow the steps included in Transitioning MBS Client Applications to the Current Release to convert the MBS application to the new RBS application, creating a different application name and application id for the new RBS application on the device. Include explicit screens/message popups within the application to alert the user to follow these steps:
    1. Submit all pending data from the MBS client to the Unwired Server.
    2. Confirm that the pending data has been submitted, delete the MBS application, and then begin using the new RBS application.
      Note: Once the application user acknowledges and confirms that pending data from the old application has been submitted, do not display the popup/screen messages again.
    3. Subscribe and synchronize the new RBS application with the upgraded Unwired Server.
For more in depth steps to transition your MBS client application to RBS, see Transitioning MBS Applications to the Current Release (2.1.3 ESD #3 or Later)
Note: For Scenario 2 and 3, there is no data transitioning solution when migrating MBS applications to RBS applications. After the application is converted to RBS, the application user must synchronize the application with the Unwired Server. The new application will not use the data residing in the device database for the old application so the application user will need to delete the old application from the device. If the old application is not removed from the device, the database for the old application will continue to reside on the device; this may double the space consumed on the device when the new application downloads records to the new database.
Parent topic: iOS