Your trial has expired / EVALUATION_EXPIRED / Sandbox has expired

A consulting team has been building a demo environment for a prospective client. The demo includes a custom Lightning app, a few flows, and seed data covering Accounts and Opportunities. On the morning of the kickoff meeting, the team lead logs into the org to do a final walkthrough and sees a banner across every page: "Your trial has expired." The login screen now redirects to a contact-sales page. Hours of work are sitting behind a paywall, and the demo is in three hours.

What the platform is checking

Salesforce trial and sandbox orgs have a fixed lifespan. A Developer Edition org is essentially permanent for development use. A trial org (the kind you sign up for through the Salesforce trial portal) has a 30-day expiration that triggers when the calendar runs out. A sandbox has its own expiration tied to the parent production org's contract and to the sandbox refresh policy.

The platform tracks the expiration date on the organization record. When the current date crosses that date, an automated process disables interactive access. Users see "Your trial has expired" on login. API access typically continues for a short grace period to let integrations export data, but eventually all access ends. The EVALUATION_EXPIRED error code surfaces in API responses when an integration tries to log into an expired trial.

For sandboxes, the trigger is slightly different. A sandbox is locked when its parent production org cancels or downgrades the license tier that included the sandbox. The lock removes write access while preserving the data for a grace period in case the org is reactivated. The same EVALUATION_EXPIRED (or in some sandbox cases, INVALID_LICENSE) error fires for client integrations.

The platform's reasoning is contractual. Trials are free time-limited evaluations; their value is in letting prospects evaluate the product. Sandboxes are subscription features. Both have lifecycle states that the platform enforces automatically to honor the contract terms.

The broken example

A demo workflow that depends on a trial org reaching the kickoff meeting in usable shape:

Team activity log
Mar 1: Sign up for Developer Edition trial. Org provisioned with 30-day expiration.
Mar 5: Install custom unmanaged package with Lightning app and seed data.
Mar 12: Add three Flows covering Lead conversion, Opportunity stage automation.
Mar 19: Build dashboard for executive scorecard.
Mar 28: Run a rehearsal. Everything works.
Apr 1: Trial expires. Login disabled.
Apr 1, 9 AM: Team opens the org to prepare for the 1 PM kickoff. Sees the expiration banner.

The work is intact. The data is intact. The org is read-restricted and login-restricted. The team has no admin access to extend, no way to log in interactively, and no way to bring the demo into the meeting unless they migrate the work to a fresh org or get the trial extended through their account executive.

A second shape: a developer who built an integration POC against a trial org. The POC integrates an external order system with Salesforce. The integration's OAuth tokens were issued by the trial org. After expiration, the integration receives EVALUATION_EXPIRED errors on every API call. The external system has been silently failing for two days because no one noticed the silent error.

A third shape: a sandbox used for user acceptance testing. The parent production org changes its license tier and loses access to one sandbox type. The sandbox is locked. Tests cannot run, and the testing window for a release narrows. The team's testing plan slips.

The fix, three paths

Migrate the work to a non-expiring org. When a trial reaches expiration with valuable work inside, the recovery path is to export everything and import it into a Developer Edition org or a permanent partner org.

For metadata (Apex, LWC, Flows, custom objects, profiles, page layouts), use the Salesforce CLI to retrieve the metadata into source format:

sf project retrieve start --target-org expiringTrial \
  --metadata "ApexClass,LightningComponentBundle,Flow,CustomObject,Profile,PermissionSet"

For data, use the Salesforce Data Loader or Workbench to export records as CSV. Each object that holds data the demo needs (Accounts, Contacts, Opportunities, custom objects) requires a separate export.

Once both sides are exported, deploy the metadata to a fresh Developer Edition org and import the data using Data Loader's Insert/Upsert operations. The work is recovered; the kickoff can proceed.

This path takes hours to days depending on the volume. For a kickoff in three hours, this is a stretch.

Request an extension through the account executive. Salesforce account executives can extend trial expirations for prospects who are actively evaluating the product. An email or a quick call to the AE can buy 7-30 additional days. For a demo with a clear sales opportunity attached, this is usually granted quickly.

The extension does not happen automatically. The team has to contact the AE, explain the timing, and request the extension. If the trial is for a prospect (not for internal use), Salesforce has every incentive to keep the evaluation alive.

For sandboxes, the equivalent is contacting your Salesforce account manager to restore the license. Restoration usually requires a billing adjustment and a defined window.

Build with longevity in mind. The long-term fix is to never depend on a trial org for production-grade work. Developer Edition orgs are free and do not expire. Partner Developer Edition orgs (available to Salesforce partners) offer higher limits and do not expire. Building the demo in a non-expiring org from day one removes the deadline pressure.

For sandboxes, the equivalent is keeping refresh schedules current and tracking the org's license entitlements in a place the team checks before relying on the sandbox.

The fixed example

A pre-flight checklist that prevents this class of failure:

Trial / Sandbox Lifecycle Pre-Flight
1. Identify the org type. Trial, Developer Edition, sandbox, or production?
2. Look up the expiration date in Setup > Company Information.
3. If a trial, count the days remaining. If fewer than 7, decide:
   - Migrate to a Developer Edition org now.
   - Request an extension through the account executive.
4. If a sandbox, confirm the parent production org's license tier still includes the sandbox.
5. Document the expiration date in the project plan with a notification 14 days prior.
6. Repeat the check before any major milestone (rehearsal, demo, go-live).

Running the checklist at project start and at every major milestone catches expiration risks while there is time to do something about them.

Edge case: expired tokens after expiration

Even after a trial is extended or restored, OAuth tokens issued before the expiration may remain invalid. Integrations need to be re-authorized through the OAuth flow to receive fresh tokens. A quick check on the connected app's session list or a re-run of the OAuth authorization flow confirms the integration is back online.

Edge case: data preservation after a trial expires

Salesforce retains expired trial data for a limited period (usually 30 days) before purging. During the retention window, the org can be restored with the same data if the license is reactivated. Beyond the window, the data is gone permanently. Teams that intend to recover an expired trial must act within the window.

For sandboxes, the lock-then-purge schedule is governed by the contract and the sandbox refresh policy. Production data has separate retention rules.

Edge case: managed packages installed in a trial

A managed package installed in a trial org is licensed to that org. When the trial expires, the package's license terminates. If the team migrates the metadata to a new org, the managed package needs to be installed fresh in the new org, and any references in the migrated metadata to the package's namespace need to remain valid (the package is typically the same in both orgs, so namespaces match).

Defensive habits

Build customer demos in dedicated Developer Edition orgs that do not expire. Reserve trial orgs for the prospect to play in themselves, not for the demo build.

Track org expirations in a central tool. A spreadsheet or a calendar event 14 days before expiration gives the team a buffer.

Automate data backups. A scheduled export of critical data to S3 or to a backup tool means that if an org disappears unexpectedly, the data is recoverable from outside Salesforce.

Document the org lineage. Every demo should record which org it lives in, which Salesforce account executive owns the relationship, and which team members have access. When an expiration warning appears, the right people get notified quickly.

Test patterns

There is no Apex test for org expiration; the lifecycle is platform-managed. The test discipline is operational: dry-run the demo flow far enough in advance that a recovery is feasible if the org is expired.

Diagnosing in production

When you see "Your trial has expired" or EVALUATION_EXPIRED:

1. Confirm the org type: Setup > Company Information shows whether the org is a trial, a sandbox, or production.
2. Check the expiration date.
3. Contact the Salesforce account executive immediately if extension is the right path.
4. Start the data and metadata export in parallel in case migration is needed.
5. Inform stakeholders of the timeline.

The error itself is a binary: the org is expired or it is not. The work is in the recovery, not in the diagnosis.

Anti-pattern: assuming trial orgs are permanent

Some teams treat a trial org like a Developer Edition org because both are "free Salesforce instances." The shapes are similar but the lifecycles are different. A trial expires after 30 days; a Developer Edition does not. Knowing the difference before depending on either prevents most expiration crises.

Anti-pattern: ignoring expiration warnings

Salesforce sends multiple email warnings before a trial expires. Teams that route these notifications to a shared inbox and never read them are surprised on expiration day. Setting up direct notifications to the project lead's primary email avoids the surprise.

Quick recovery checklist

1. Confirm the org type and expiration status.
2. Request an extension or restoration if appropriate.
3. Export metadata and data in parallel for migration if the recovery path is migration.
4. Spin up a Developer Edition org as the migration target.
5. Deploy metadata and import data.
6. Re-authorize any external integrations.
7. Communicate the new org id to all stakeholders.

The expiration itself is rarely the surprise. The surprise is the timing. Building lifecycle awareness into the project plan keeps the timing under control.

Further reading from Salesforce

• Salesforce Help: Trial Org Expiration and Conversion
• Salesforce Help: Sandbox Refresh and License Management
• Developer Documentation: Developer Edition Orgs
• Architect: Org Strategy and Environment Management
• Trailhead: Salesforce Platform Basics