Start here
Your first workload
Start with one application your team understands. You can review what we discover before deciding what to test.
Last reviewed 23 October 2026
Search runs in your browser. No account needed.
PortabilityLabs is in private early access. Request access first; joining the waitlist does not create a workspace, connect AWS or start a test.
1. Open your workspace
At the portal, choose Sign in if you already have access. If you are new, choose Request early access to join the waitlist. Wait for an invitation before connecting AWS.
After you are invited, sign in and create or join your organisation. A project groups related workloads. Use a name your team recognises, such as “Customer services”.
Use Help or the guide link beside a workload step when you need an example. Guides open in a new tab so your workspace and current selections stay in place.
The workspace is separate from the public guides and is marked for exclusion from search indexing. Sign-in and organisation permissions control access.
You do not need a target cloud, regulatory questionnaire or production data to get started.
2. Connect AWS
Open Connections in workspace settings. Choose AWS and the accounts and regions to include. Your AWS administrator installs the role supplied by the setup flow. We use temporary role sessions rather than asking for permanent access keys.
Run discovery and wait for it to finish. Review any permissions that could not be used; a successful scan does not mean every AWS service is covered.
AWS connection and discovery guide →3. Add a workload
Select Add workload, choose AWS, then choose discovered resources. Search by name, ARN or reference and filter by AWS resource type. Select the resources that deliver one useful capability, such as an orders API with its function and table.
Review the Workload map. Confirm the resources and connections, and resolve questions that affect the test you want to run.
Choose and maintain a workload →4. Say what must still work
Open Success criteria. Choose a workload entry point or measurable result and add a required check. For an API, start with a response your caller needs. For a processor, start with the output or effect that marks a successful job.
Review inferred test data. You can accept the synthetic starting values or replace them with a static mock. Use made-up values, never live customer records or credentials.
Define useful success criteria →5. Run and read the result
Return to Check portability and select Run portability test. If a step is missing, follow the named action shown there. The result lists the checks, test time, execution method, limitations and cleanup.
A passing simulation confirms the configured behaviour. Original application execution requires separately approved material and an available execution environment.
Run a test and understand the evidence →