Know what to expect.

No. Start with a workload you would need to keep running if your current cloud arrangement changed. The purpose is to identify uncertainty early and keep evidence you can review before an exit becomes urgent.

For supported AWS resources, you can review discovered configuration and connections, define success criteria, run a synthetic contract test and retain its scoped result. The result explains what passed and what remains untested. It is not an automatic migration of the original app.

No. Current source discovery covers 17 resource families and selected relationship patterns. Containers, many databases and host-level application inspection remain important gaps. Inventory, packaging and original-application execution are different levels of support.

Hosted AWS discovery uses temporary role sessions with the supplied read permission pack. You select the accounts and regions. Workload-scoped Lambda retrieval uses a separate worker. You should review the role rather than grant AdministratorAccess or send access keys.

Inventory excludes records, object contents, message bodies, request payloads, secrets, environment-variable values, logs and tags. Optional resource names can still be sensitive. Selected Lambda ZIPs can be retrieved separately into encrypted quarantine; custody does not authorise execution.

No. Define the workload outcomes that need to survive. A target may merge or split components if those outcomes and explicit operating requirements still pass. Internal checks are useful diagnostics, not an automatic one-for-one design requirement.

It means the required checks passed for the recorded package, workload revision and execution method at that time. A simulation pass confirms configured synthetic behaviour. It does not demonstrate that original application code, production data migration, load or cutover worked.

The current schedule repeats tests of the pinned workload definition. Automatic source rediscovery and change comparison are not yet included. After AWS changes, run discovery, review the workload and test the new revision.

Technical evidence can support a wider exit-planning or operational-resilience programme. PortabilityLabs does not determine regulatory applicability, certify compliance or submit a DORA register. Your risk, legal and business owners still define the service, scenario, governance and acceptance.

There are two designs: customer-hosted collection/testing with the managed portal, or a sovereign installation with the portal, control plane and evidence inside your boundary. These require agreed implementation and acceptance; they are not self-service installations today.

A live review window requires an approved execution option, a defined expiry and teardown controls. Hosted application execution is gated for eligible, verified customers. Evaluation or demo access does not allow unknown code to start in a hosted environment.

You reach the WorkOS waitlist for PortabilityLabs. Entering your email requests access; it does not create a workspace, connect a cloud account, start infrastructure or charge a plan fee. We contact you before enabling a workspace.