Step 1. Prepare installed template to migration.

Update installed template with template available by URL:




This template will remove installed resources except DynamoDB tables. It is required to avoid resource name conflicts with template v3.

Step 2. Update template to version 3.0. 

Update template with template v3 available by URL:

Version 3.0 installs an RDS Server with all of the customer Account information, this get's synched back to Thinglogix Account. There is also the option to have this RDS database housed within a VPC to prevent public access. To configure the VPC select "true" for "UsePrivateVPC":

Displaying Screen Shot 2018-10-23 at 11.19.24 AM.png

 If VPC is enabled RDS DB in private subnet and have no public access, all lambdas that working with RDS (95% of lambda functions) in private subnets too.

Displaying Screen Shot 2018-10-15 at 11.56.45 AM.png

Database Name: 'AdvancedSearch'

Username: search_user

Password: random string for each customer. 

You can find password in EC2 -> Parameter Store(1) -> RDS_PASS_<environment>(2) -> Value(3)

How to verify that data migration completed successfully

We start Data migration in init Lambda during installation CloudFormation template. If the Template are updated success, that mean that data were migrated success too.

New template has additional parameters:

InstallRDSTemplate - use Customer’s RDS for advanced search and User/Account data

FoundryUsername - username of existed Foundry Admin user belong to Parent Account Id

FoundryPassword  - password of existed user with username specified in FoundryUsername. This credentials are used on updating template step only and will not be stored.

ParentApiEndpoint - API Gateway endpoint of parent account. Currently it should be ThingLogix API Gateway endpoint

(for dev environment:

SesEnabled - flag which indicate that customer’s SES can be used for sending activation/forgot password emails. SES should be moved out of the sandbox for sending to any email address. Currently select TRUE for ThingLogix AWS account, FALSE for others.

S3BucketName - existed S3 bucket in Customer’s AWS account (not ThingLogix!)

All parameters are required.

If you install template v3 on new AWS account you will not need to configure credentials(API Gateway Endpoint, Cognito Identity Pool Id, Cognito Developer Provider Name)  on Foundry side because template will do it.

Internal migration of User/Account data process 

When you update/install template v3 with enabled RDS it will run lambda for migration User/Account data from parent to local RDS.

Dynamdb table Naming

When installing Version 3.0 of Foundry, the DynamoDB tables will retain their existing Name. So if they were named “_dev” they will keep the same name.

Account Syncing

On the Client RDS there is a Postgres Database called “AdvancedSearch”. You can connect to this DB using the Endpoint from Client AWS RDS instance:

User: “search_user”

Pwd: see Step 2.

This Database is used for the Advanced Search Functionality as well and creating tables for any “Searchable” Attributes of a particular Object type

Update the other applications

  1. Old RDS DB usage.

In Foundry V3 NOT used RDS DB with endpoints:


All application that directly connect to those DBs should be updated for support Foundry V3.

Old RDS DBs will not be synced with Foundry V3.

  1. Custom Lambda Functions

In Foundry V3 are deleted lambda function: “fndy-any-redirect-to-thinglogix-secure”. 

All applications (lambdas) that directly invoke this lambda function should be updated for support Foundry V3. (Customers: Yankee, SafeRide and etc. )

  1. Direct Lambda invocations

Please don’t use {“invoke”:true} with Post, Put, Delete lambdas. It caused error with sync RDS DB.