The original App Engine architecture is based on a single frontend instance with optional backend instances. If you plan to use modules with an existing app, you will need to migrate your frontend so it is handled as a module. You may also want to convert any existing backends to module format to take full advantage of the additional functionality that modules provide (like the ability to version backends). This page describes both processes.

1. Migrating an existing frontend to Modules
2. Converting backends to Modules

Migrating an existing frontend to Modules

When you run an app with a single (non-module) frontend instance, you use the Admin Console to customize the frontend performance settings. The settings are found on the Administration>Application Settings page, in a section named Performance . The frontend performances settings are:

• Frontend instance class
• Min/Max Idle Instances
• Min/Max Pending Latency

With the advent of modules, the frontend is treated like any other module; its performance settings are included in its yaml file.

Before you can start using modules in an existing app, the frontend settings must be migrated to module settings. After migrating, your frontend instances are managed as modules with the same settings. There are two ways that migration can happen:

Automatic migration

If you have not specified any custom frontend settings, migration occurs automatically the first time you upload any module. You don’t need to take any special action.

Manual migration

If you’ve changed any of the frontend performance settings, you can’t upload module files until you’ve migrated manually. A section titled Performance Settings Migration for Modules appears in the Admin Console below the Performance section. This section displays code snippets that define an automatic-scaling module with performance settings equivalent to the current frontend. You can copy this code and use it to redefine your original frontend source file as a module. Press Migrate Settings to perform the migration. The app continues to run and you can now upload modules.

Once you’ve migrated the frontend, the performance settings will no longer appear in the Admin Console.

Migration is not reversible. After you have migrated, you should define and deploy app components as modules. If you upload an old-style yaml config file without a module tag, it will become the new default module.

Converting backends to Modules

If you have an existing application that uses backends, App Engine automatically runs each backend as a new, non-default version of the default module. Resident backends are assigned manual scaling and dynamic backends are assigned basic scaling.

You can convert backend instances to named modules that are versioned and have explicit scaling type and instance classes. You must replace the original backends.yaml file with multiple .yaml files as shown below.

For example, here is a fragment from a yaml file that defines three backends ( memdb , worker , and cmdline ):

backends:
- name: memdb
  class: B8
  instances: 5
- name: worker
  start: worker.app
  options: failfast
- name: cmdline
  options: dynamic

To convert these backends to modules, create a separate yaml file for each one. In memdb.yaml :

application: myapp
module: memdb
version: uno
instance_class: B8
manual_scaling:
  instances: 5

In worker.yaml :

application: myapp
module: worker
version: uno
# For failfast functionality, please use the ‘X-AppEngine-FailFast’ header on requests made to this module.
manual_scaling:
  instances: 1
handlers:
# If a module has an _ah/start handler, it should be listed first.
- url: /_ah/start
  script: worker.app

Note that the original definition of the worker backend used the start: tag to bind the script worker.app to the _ah/start path. For modules, this binding is defined as a handler with the explicit _ah/start path. Additionally, if there's more than one handler, the _ah/start handler should be listed first.

In cmdline.yaml :

application: myapp
module: cmdline
version: uno
basic_scaling:
  max_instances: 1

The Python SDK contains a script that can perform these transformations for you. Given two yaml files, one for the app and one for its backends, it creates new yaml files defining modules for each backend. Using the migration example above, assume the original file defining the three backends is called backends.yaml , and the file defining the main app is app.yaml . The script would generate three new yaml files: memdb.yaml , worker.yaml , and cmdline.yaml . Here is how to call it:

$ path-to-sdk/backends_conversion.py backends.yaml app.yaml

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 3.0 License , and code samples are licensed under the Apache 2.0 License . For details, see our Site Policies .