The app moves with you; the tenant's configuration does not

An Extend app's source code, versions and builds are stored in App Hub on the Developer Site, not in the WCP Development tenant, so a new tenant only needs the app deployed to it. What you configured inside the old tenant (business object data, domain and business process security policies, custom tasks, integration system users, Cred Store entries, app attributes, custom reports) stays behind and has to be exported, re-created or migrated.

Concept: App Hub describes three layers: source code, a build pipeline that turns source into artifacts, and artifact storage. A Development tenant consumes those artifacts when you deploy. That is why losing a tenant doesn't lose the app, and why the reverse is dangerous: once you delete an app from App Hub, you can no longer reach it on any Development tenant it was deployed to.

When a Development tenant goes away

The Developer Guide documents two ways a Development tenant ends. A Personal Account (Open Developer Program) tenant expires if nobody signs in to it for 7 consecutive days. Any Development tenant can also be deleted from Console > Tenants on the Developer Site, which permanently removes its data and configuration. The guide describes no scheduled retirement of older Development tenants and no Workday tool that copies apps or data from one Development tenant to another, so if you've been told to move off an old tenant, the method below is the same one you'd use for an expiring one.

Personal accounts have two more limits that shape the move: 1 active Development tenant at a time, and no more than 2 Development tenants within 6 hours. You can't run the old and new tenants side by side, so anything you want from the old tenant has to leave it as a file before you create the replacement. If it has already expired, the app is still in App Hub; the docs give no way to get its data back.

Company accounts don't have the one-tenant rule. A Company Administrator can create as many Development tenants as the Extend contract allows, so the new tenant can be built and checked before the old one is deleted. Alias reuse follows rules on Concept: WCP Development Tenants: a deleted tenant's alias (for example acme_wcpdev1) is reused only after the original is fully deleted; create the new tenant first and it gets the lowest free number, such as acme_wcpdev2. Anything that has the old alias written into it, such as wdcli commands in scripts, needs updating if the alias changes.

Before the old tenant goes: what to take out

  1. Keep a copy of the source outside App Hub. On the app's home page, choose Download Source from the menu to get a ZIP of the app, or run wdcli app download <appRefId> --latest-version. App Hub already holds the app, but a local copy, ideally committed to Git, protects you from an accidental App Hub delete. Version control for Extend with GitHub covers keeping that copy current.
  2. Export business object data. Extend business object instances live in the tenant. Build a custom report on the business object, select Enable As Web Service on its Advanced tab, and run an outbound EIB with that report as the data source, as in Extract Data from Extend Business Objects Using EIBs. Download the file from the EIB's Output Files tab.
  3. Record the App Manager configuration. In App Manager, select the app and click Configure. The Configurations tab shows the security domains, business processes, profile groups, tasks and reports, plus tiles for ISUs, App Attributes and Custom Tasks. Note each one; on a personal account you rebuild them by hand.
  4. Note Cred Store entries. Entries made with the Create External Client CredStore task (OAUTH2, OAUTH_CLIENT_CREDENTIAL, legacy WCPISU refresh tokens) belong to the tenant. Record each App ID and External Reference ID, because the SMD's authTypes and any orchestration credential set to Cred Store Reference look them up by those values. Leave the secrets out of your notes; re-enter them from the third-party system.
  5. List custom reports and calculated fields built on your business objects. They are tenanted configuration too.

Deploy the app to the new tenant

When the new tenant shows Running on the Tenants page, sign in and change the temporary password within 72 hours, then deploy. On the Developer Site, open Console > Apps, select the app, and use the Promotions tab, which deploys apps to Development tenants. App Builder's Save and Deploy also asks which Development tenant to deploy to. From the command line:

wdcli tenant login <new-tenant-alias>
wdcli app deploy <appRefId> --tenant-alias <new-tenant-alias> --version <version>

Run this as yourself. A WDCLI system user can't run tenant-level operations such as deploying, so a deploy script that logs in with wdcli auth login --system-user still needs a tenant sign-in. The IntelliJ plugin's Deploy Apps to Development Tenants page notes that the first deploy to a tenant also installs the app there. If App Manager on the new tenant shows the app on a Needs Attention tab, Workday's instruction is to redeploy it to the Development tenant.

Re-create the tenanted configuration

Security comes first because later steps assume it is in place; for example, Workday lists domain security policies for the app's model security domains as a prerequisite for assigning an ISU.

  1. Security. On App Manager's Configurations tab, create domain security policies for the app's security domains, then click Activate Pending Security.
  2. Business processes. Create the business process definitions and their business process security policies.
  3. ISUs. If the app uses the simplified ISU scheme, run Create Integration System User, add the user to an Integration System Security Group (Unconstrained) with the View/Modify and Get/Put permissions the app needs, and run Activate Pending Security Policy Changes. Then in App Manager click Add Integration System User, pick the ISU, and click Create API Client on its row. The username in the SMD's ISU auth type must match that ISU, and an ISU can be associated with only one app. Simplified ISU errors covers what fails when a step is skipped.
  4. Cred Store. Re-create each entry with the same App ID and External Reference ID. Orchestration credentials themselves are defined in the orchestration's Settings > Credentials tab and travel with the app; only the Cred Store entries they reference have to be rebuilt.
  5. App attributes and custom tasks. Re-enter attribute values for this tenant. Workday's migration reference says custom tasks must be re-created, including any worklets or dashboards that use them.
  6. Data. Load the exported instances with an inbound EIB, choosing Extend Spreadsheet Template as the file type, as in Load Data to Extend Business Objects Using EIBs. The Extend business object data loading guide goes through the template and its errors.

Company accounts: copy configuration with Object Transporter

With both tenants alive, you don't have to rebuild configuration by hand. Workday supports migrating tenanted configuration items, including Extend model components, from one WCP Development tenant to another with Object Transporter, per Steps: Migrate Tenanted Configuration Items. The model components must already be installed on both tenants, so deploy the app first. Each WCP Development tenant needs a one-time Customer Central access setup, and a Customer Central session to it lasts 30 days.

Steps: Reuse Tenant Configurations names what Object Transporter can't carry: an EIB integration system that contains Extend model components, and security configuration packages. Custom tasks still have to be re-created. The general mechanics are in moving Workday configuration between tenants.

How to prove the move worked

Check these on the new tenant before deleting the old one (company accounts) or before treating your export as complete (personal accounts):

  • App Manager lists the app on the Custom Apps tab and shows no Needs Attention tab.
  • The Extend Business Object Instance Count tab in the app's details matches the row counts you exported.
  • Each page opens for a user in the intended role and is refused for one outside it. A proxy access policy restricted to the WCPDEV environment lets you start a proxy session as another persona in a Development tenant to check this.
  • Each orchestration runs once and shows SUCCESS in Orchestration Activity, which proves its credentials resolved in the new tenant.

On a personal account, the 7-day rule now applies to the new tenant, so sign in to it well inside every 7 days.

Sources checked