Home Platform 2023 Refresh migration

2023 Refresh migration

We are working on migrating all customers to the 2023 Refresh by Q3 2024.

If you would like to prioritize your migration to the 2023 Refresh, reach out to our support team.

This article discusses the steps that are involved in evaluating and then migrating a tenant to the 2023 Refresh.

See 2023 Refresh Platform overview for information about the architectural and feature changes in the 2023 Refresh.

Migration process

Provision new tenant

See New Tenant Creation for the data points needed in order to provision a tenant.

Refactor workflows that use unsupported Nodes

See Replacement of deprecated Nodes for a list of all Nodes that are not supported and how they should be migrated.

Reduce large Variable Bar Input/Output Property sizes

The 2023 Refresh requires that property values declared on a Variable Bar do not exceed 10KB. This applies only to Default Variable Bar Properties (it does not apply to Configuration or Hidden Properties).

If a Property exceeding this size limit is encountered during migration, the Workflow will be transferred but not published and a warning will be shown.

Properties that exceed this limit usually contain unnecessarily long sample data and can easily be reduced to a smaller representative sample where needed.

If the affected Properties are trimmed in the legacy platform prior to migration, no warning will be given and no further action is needed.

If the migration is run first, it will be necessary to trim the Properties in the 2023 Refresh platform and re-publish the affected Workflows.

Perform initial migration

We will perform an initial migration of all assets in the old platform to your new tenant. This includes Site resources (Workflows, Connections, DropPoints, API keys and Users) and Account resources (Subscriptions and Users).

Note that Always On Workflows will be migrated in a disabled state.

HTTP-Bound Workflows will not be invoked because at this point the DNS records for sub-domains are still pointing to the legacy platform.

Configure DropPoint endpoints or upgrade DropPoints

DropPoints that are easy to access should be upgraded to the latest version available from the new Console.

DropPoints that cannot be easily accessed, can be configured server-side to connect to the new tenant.

Upgrade DropPoints

This is the preferred option.

Obtain the DropPoint installer from the DropPoints Pane in the new Console at https://app.flowgear.net.

Uninstall the old DropPoint and use the new installer to install the new DropPoint. The config.json file is preserved in the install folder so when the new DropPoint starts it will have the same identity.

Under the Configure Endpoints textbox in the installed DropPoint UI, capture in both the domain for the tenant as well as any legacy platform endpoints that are needed. This enables the new DropPoint to connect to both the old and new platform.

The following table lists the endpoints that should be specified based on the region of the legacy platform:

Endpoint Location
api1.flowgear.net South Africa North
api3.flowgear.net North Europe
api6.flowgear.net East US

Here is an example value for Configure Endpoints that will cause the DropPoint to connect to both the legacy platform and a new tenant:

api6.flowgear.net
sometenantname.flowgear.net

Configure legacy DropPoint to connect to new tenant

This option should only be used if it is not possible to upgrade a DropPoint due to there being no remote access to it.

With this option, the new platform will not be able to verify the client-certificate for Mutual TLS which is not recommended for production use cases.

Log a service ticket noting the DropPoint ID. A record will be created within the legacy platform that instructs the DropPoint to connect to the new tenant account as well as the legacy platform.

Test Workflows

Verify that Workflows are functional as follows:

  • On-Demand Workflows can be run from the Run Now Pane
  • Always On Workflows can be activated from the Run Now Pane. Before enabling, consider whether the corresponding Always On Workflow should be stopped in the legacy platform first
  • HTTP-bound Workflows can be tested by changing local DNS records in your HOSTS file on Windows.

Creating a local HOSTS file record

  • Ping your tenant name to determine its IP address. Example: mytenant.flowgear.net resolves to 102.37.123.57
  • Open the HOSTS file at %windir%\System32\drivers\etc\hosts in Notepad (you must open as Administrator)
  • Add an entry to temporarily point your API-bound domain to the IP address of the new tenant. For example, if your API-bound sub-domain on the legacy platform is mycompany.flowgear.net, add the entry 102.37.123.57 mycompany.flowgear.net to the HOSTS file and save changes
  • Use a tool like Postman to test API invokes

Agree a cut-over time and perform cut-over

Discuss a cut-over date and time with Flowgear. At this time, the following actions will be taken:

  • The DNS record for your production sub-domain (e.g. mycompany.flowgear.net) will be pointed to the new tenant
  • Always On Workflows in the legacy platform will be stopped
  • Always On Workflows in the new platform will be started
  • We recommend locking as many users as possible out of the old platform to prevent accidentally logging in to it

One month after cut-over, we will deprovision the legacy platform.