Evaluate PortabilityLabs

A clear decision.
Before you connect.

Start with one application you might need to move. Check the fit, involve the right people and agree what would make the first result useful.

Plan your evaluation →Download the buyer brief

No account or cloud access needed. Reviewed .

Your evaluation

Four decisions. No guesswork.

Review the first three steps using the public material. Request access only when the fit is useful.

  1. 1

    Does your application fit?

    Start with its AWS services and dependencies—not the whole account. Check what can be discovered, what can be simulated and what is not covered.

    Check AWS workload fit →
    Bring: service list
    Decide: useful scope
  2. 2

    Is the access model acceptable?

    Share the trust centre with your security reviewer. Read the actual permission scope and shared-service limits before granting any AWS access.

    Review security and procurement →
    Bring: security reviewer
    Decide: permitted boundary
  3. 3

    What would a useful result show?

    Choose one caller-visible outcome, such as submitting a request and reading its result. Agree the method and limitations; a simulation does not mean the original app ran.

    Explore the workload walkthrough →
    Bring: application owner
    Decide: success criteria
  4. 4

    Request an invitation

    The WorkOS waitlist collects your email. It does not create a workspace, connect AWS, start infrastructure or charge you. Do not submit credentials or customer data.

    Join the waitlist →
    Bring: email only
    Decide: whether to continue

Define a useful finish line

Know what you will take away.

An agreed workload boundary, a map of supported resources and connections, required success criteria, and a scoped simulator result with its time, checks and limitations.

Understand the evidence →

Current boundaries

What to confirm before live access.

Current AWS discovery covers 17 resource families and selected connections. Discovery, simulation and original-application execution are different capabilities. Check the exact AWS coverage before requesting access.

Read current limits and onboarding requirements
  • Retrieved Lambda code is quarantined, not executed. A simulation pass is not proof that your original application migrated.
  • Scheduled monitoring repeats the pinned workload definition; it does not automatically rediscover changes in AWS.
  • Customer-hosted and sovereign deployments are designs requiring agreed implementation and acceptance, not self-service installations.
  • Hosted privileged workers and data services remain shared. Stronger customer-specific containment is required before broad live-customer onboarding.
  • Legal contracting identity, privacy and processing terms, retention and deletion, working support/security contacts and any service levels must be agreed before live onboarding.

Read the hosted compromise boundary and AWS access-removal steps. A policy or diagram is not independent assurance.

Sharing this internally? The plain-text buyer brief includes the same scope, current limits and review links. It contains no customer data or deployable code.

Request early access →Read the setup guide