How to export your data from Appian

How to export your data from Appian before a contract ends

Appian packages export the design layer and its supporting files, but business data in your data stores does not move through a package. If a renewal, price change or exit decision means you must get application design out of Appian, the documented path is the package. A package bundles design objects such as process models, record types, interfaces, decisions and integrations, together with import customization files, database scripts, referenced plug-ins and application configurations. That covers the logic of your applications. It does not cover the rows held in the databases and data stores your applications read and write, the documents in your file storage, or the users and credentials in your identity systems. Plan for those as separate workstreams with their own owners and extraction methods.

Before you start, inventory each application against the package limits Appian documents: individual database script files of up to 20 MB, up to 100 MB of database scripts per package, and up to 500 packages per application. If a package exceeds any of these, you will need to split the work and confirm with Appian how the split should be sequenced. Note also that Appian maintains plug-ins at the environment level rather than the application level, so a plug-in referenced by one application may be shared by others, and its licensing and source must be traced separately. Ask Appian or your administrator to confirm which plug-ins each package references and whether you hold their binaries and source. Check the current package documentation in your version of Appian's help site, because export behavior is tied to the release you run.

The practical output of this step is a register, not a file. For each application, record the packages, the database scripts they contain, the plug-ins they reference, and the data stores and external systems behind them. Then ask your team which of those data stores you can extract directly, and in what format, with your own database tools. Illustratively, a claims application might export cleanly as a package while its case history lives in a separate database that needs its own export, schema mapping and reconciliation. Keep this register as the baseline for the migration scope, since the same gaps will decide what a replacement platform must rebuild. Confirm each item with Appian and your own environment before the contract date, not after it.

What an Appian package exports and its documented limits

This table lists what an Appian package carries, the documented size limits, and the items that stay behind when you move. Use it to build your inventory before deciding which parts you rebuild, which you export as reference material and which you extract from your own data stores. Confirm the export format and file structure against the documentation for your Appian version.

Item	What the package carries	What it means for your move
Design objects	Process models, record types, interfaces, decisions and integrations	These define the application logic you must recreate in Flowable and a custom front end. Use them as the functional specification.
Import customization files	Environment-specific values applied when the package is imported into another environment	Review each value. Settings tied to Appian environments will not carry over unchanged to a self-hosted target.
Database script files	SQL scripts shipped with the package, each up to 20 MB	Scripts show the schema changes made to the application database. Use them to rebuild table definitions, not as a data copy.
Database scripts per package	Up to 100 MB of database scripts in one package	If a package approaches this limit, split the inventory by application area so each script set can be reviewed on its own.
Packages per application	Up to 500 packages per application	Plan the inventory by package count and confirm that every package is accounted for before you start the rebuild.
Referenced plug-ins	A reference to the plug-in, not the plug-in environment itself	Plug-ins are maintained at environment level. List each referenced plug-in and find its replacement, such as a library or service, in your target design.
Application configurations	Application settings included in the package	Record each setting and decide whether it belongs in the new application, its configuration files or its infrastructure.
Business data in data stores	Not included in the package	Records and transactional data stay behind. Extract them separately from the source databases, with their own validation and reconciliation.

What stays behind when you export from Appian

A package carries the design of your Appian applications, not the data they run on or the work in progress. The cards below cover the items a package leaves out, the runtime state that needs its own plan, and the checks to run with your DBA and Appian documentation before you set a migration scope.

Business data in your data stores

Records, transactional tables and reference data live in the databases and data stores connected to Appian, not in the package. A package can carry database scripts that create schema, but it does not move the rows those scripts or your users created. Ask your DBA to inventory every data source each application reads or writes, then choose between direct database extraction, a reporting export or a data migration built by the implementation team. Confirm each approach against your own environment and the Appian documentation before you commit to it.

User-entered records and attachments

Records created by users through forms, along with uploaded files and documents, are data rather than design objects, so they stay in place when you export a package. Map which record types hold user input and where their attachments are stored. For each, decide whether to extract the rows and files directly, export them through a report, or have the implementation team write a migration job that preserves keys and relationships. Confirm with your DBA how attachment storage is referenced before extraction.

In-flight process instances

Process instances that are running when you export are runtime state held by the Appian engine. A package describes the process model but not the instances already moving through it, including their task assignments and timers. Count open instances per process and decide whether to let them finish in Appian, restart them in the target engine, or migrate their state with a tested mapping. Confirm the mapping with the target engine's documentation and with Appian support before cutover.

Plug-ins and external integrations

Packages reference plug-ins, but Appian maintains plug-ins at the environment level rather than the application level, so a plug-in your application depends on may not be present in the target. Integrations that call external systems also need their endpoints, credentials and certificates rebuilt outside the package. Inventory every plug-in and integration per application, record its version, and plan a replacement or a custom connector for each one before the package moves.

Environment configuration and credentials

Application configurations and import customization files travel with the package, but the values behind them often differ per environment, and secrets are usually not included. Users, groups, mail settings and keys must be recreated in the target system. List every value an import customization file sets, mark which ones are environment specific, and assign an owner to supply each secret through your own secrets store. Confirm which values a package carries with the Appian documentation.

Package limits that split the export

Appian limits individual database script files to 20 MB, database scripts to 100 MB per package and packages to 500 per application. An application that approaches these limits needs its scripts and packages split before export, and the split must keep dependencies in the right order. Measure your largest scripts and package counts early, because a limit hit late in the project pushes the schedule. Confirm the current limits in the Appian documentation for your version.

Using packages as the inventory for a move

A package is the most reliable starting inventory for a move away from Appian because it is the one place where the application's design objects and their dependencies are listed together. Appian packages bundle process models, record types, interfaces, decisions and integrations, along with import customization files, database scripts, referenced plug-ins and application configurations. A rebuild has to replicate each of these, so the package manifest gives you a checklist that is closer to complete than anything reconstructed from memory or from the Appian designer. Export the packages for every application in scope and keep them under version control before anyone starts mapping. Confirm with your Appian administrator that the packages cover every application that reads or writes the data you plan to move, because an application left out of the export is an application left out of the inventory.

Map each design object to a named future equivalent in a spreadsheet with one row per object. A process model usually becomes a BPMN model run by a process engine such as Flowable, a decision table becomes a DMN decision, and a case that needs ad hoc work is a candidate for CMMN. Interfaces and record views do not map to a process engine at all, so each one needs a custom front end, and the sheet should say which front end and which API serves it. Integrations and data reads need their own rows with the endpoint, the authentication method and the owner of the target system. Treat this mapping as a plan, not a conversion: no tool in the stack will translate Appian objects into BPMN, DMN or code automatically, so every row is written by hand and reviewed by a process owner. Plug-in references deserve special attention, since Appian maintains plug-ins at the environment level, so one reference in a package may point to code that other applications also depend on. List each plug-in, the packages that reference it, and the replacement code, and do not retire a plug-in until every referencing package has its row closed.

The sequence for a complete Appian export

This sequence turns Appian's package format into a verified, versioned inventory of design objects, dependencies and business data, so the migration team can see exactly what leaves the platform and what must be extracted separately.

Freeze the application baseline
Before exporting, record the current state of each application: the Appian version, the environment, the list of applications and their process models, record types, interfaces, decisions and integrations. Agree a change freeze with the application owners so the export reflects one fixed point in time. Store the baseline inventory as a signed-off document. It is done when the application owners confirm in writing that the inventory matches what is live in production.
Build and export one package per application
Using Appian's package tooling, create a deployment package for each application in scope. A package bundles design objects with import customization files, database scripts, referenced plug-ins and application configuration, so export each application separately to keep dependencies visible. Record the package name, version and creation date. It is done when every application in the baseline has exactly one package and the package list matches the inventory.
Check each package against the size limits
Appian limits individual database script files to 20 MB, database scripts to 100 MB per package, and packages to 500 per application. Check each package against these limits and split or restructure any package that exceeds them. Confirm the package count per application stays within the 500 limit. It is done when a short table lists each package with its script sizes and count, and no package breaks a limit.
Compare object counts against the design inventory
Open each package and count its design objects by type: process models, record types, interfaces, decisions and integrations. Compare these counts with the baseline inventory from step one. Any mismatch means an object was left out of the package or was added after the freeze. Investigate each difference and document the reason. It is done when every object type matches the baseline or each variance has a recorded explanation approved by the application owner.
Extract business data with the database team
Packages do not carry the business data in your data stores, such as records, transactional tables and document content. Work with the database team to define the extracts, row counts, schema versions and retention rules for each data store. Agree who runs the extracts and where the output is held. It is done when the database team signs off the extract scripts, row counts reconcile with source systems, and the data has a checksum recorded alongside it.
Record plug-in and integration dependencies
Appian maintains plug-ins at the environment level, not the application level, so a package may reference a plug-in that is installed on the source environment but absent elsewhere. List every referenced plug-in, its version, every external integration endpoint and its credentials owner. Note which integrations call systems that will remain in place. It is done when each dependency has an owner and a replacement or retention decision, and no package references an unlisted plug-in.
Restore packages in a non-production environment
Import each package into a clean non-production environment that matches the source version as closely as possible. Confirm the applications install without manual edits, the object counts match step four, and the test data loaded in step five reconciles. Record any failed imports and fix them at the source, then re-export. It is done when every package installs cleanly, and the restore log is attached to the inventory.
Store everything in a versioned repository
Place the packages, data extracts, checksums, plug-in list, dependency register and restore log in a versioned repository with access controls and an audit trail. Tag the commit that represents the frozen baseline and keep a read-only copy. Confirm the repository is in the target infrastructure or a location your data residency rules allow. It is done when a second team member can clone the repository, locate every package and extract from the index, and verify the checksums.

Questions buyers ask about exporting from Appian

How much effort does exporting from Appian actually take?

The export itself, creating packages from your applications, is usually the smaller part of the work. The effort comes from inventorying what each package holds, checking which design objects depend on plug-ins and integrations, and deciding what the target platform must rebuild. Effort rises with the number of applications, the number of packages per application, the volume of database scripts and the count of custom plug-ins. Ask any provider for a written inventory method and a list of assumptions behind the estimate, so you can see how each driver was counted.

How long does an Appian export take, and what drives the duration?

Duration depends on scope rather than on the export button. The main drivers are the number of applications and packages, how many design objects reference shared components, the size of database scripts (Appian limits individual script files to 20 MB and 100 MB of database scripts per package), and how many plug-ins must be identified and replaced. Plug-ins are maintained at the environment level, so a plug-in shared by several applications adds coordination across teams. Ask for the duration as a schedule tied to named milestones in the written scope, not as a single number.

What does the work need from our Appian admins, DBAs and architects?

Appian administrators need to confirm which applications and environments are in scope, provide access to package creation and deployment, and identify which packages are current. Database administrators must supply or confirm the schemas and scripts that back custom data and check what stays in your own data stores. Architects need to map integrations, identity sources and plug-in dependencies, and decide which process models and records move to the new platform. Agree these time commitments in writing before work starts, because delays on any of the three roles usually hold up the whole inventory.

Can our team export from Appian without outside help?

Yes, an internal team can create packages and inventory them with Appian's own tools, provided it has the Appian skills, database access and time to do the analysis. The harder part is judging what a package does not carry and what the target system must rebuild. Most teams underestimate the plug-in review and the business data migration, which sit outside the package. An outside partner usually adds value on dependency mapping and on written evidence of what was moved. Whichever route you take, keep the inventory as a versioned document that your auditors and future engineers can read.

Does an Appian package move the full application?

No. A package bundles design objects such as process models, record types, interfaces, decisions and integrations, together with import customization files, database scripts, referenced plug-ins and application configurations. It does not carry the business data in your data stores, the runtime state of running processes, or the users and groups in your identity system. Plug-ins are also managed at the environment level, so a package references them rather than fully reproducing them. Treat the package as the design inventory for the move, and plan a separate path for data, identity and running work.

What is left behind when we export from Appian?

The main items that stay behind are the business data in your databases and data stores, in-flight process instances, and any configuration held outside the package. Identity sources, external system credentials and environment-specific settings also need to be recreated on the target. Plug-in code is referenced by the package but must be sourced, reviewed and rebuilt or replaced for the new platform. Ask the provider to list each of these categories in the written scope with an owner and a method for each one.

What does a DeployOpen engagement cover for an Appian export?

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, and an engagement for exporting from Appian can cover the inventory of packages, plug-ins and database scripts, a dependency map, and the written record of what moved and what stayed. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not publish a price list, so a quote follows from the written scope. Ask for the exact list of applications, packages and deliverables in that scope, and who on each side signs off on the inventory.

What to plan before the Appian contract renewal or termination

Most of the work in moving off Appian is decided before the contract ends, not after. The version you run, the length of the export and parallel run, what you must retain or delete, and the target platform all depend on each other. Confirm the contract terms early, because they set the deadline for everything else.

Confirm your self-managed version

Check whether your self-managed environment is on 25.3 or earlier. Appian's documentation states that from 25.4, self-managed Appian runs only on Kubernetes, and 25.3 is the last version supporting non-containerized deployment. Environments on 25.3 or earlier keep receiving hotfixes for that version's support lifetime but cannot upgrade to 25.4 or later without migrating to Appian on Kubernetes or Appian Cloud. Ask Appian for the support end date for your exact version in writing.

Set the export and parallel run length

Packages carry design objects, customization files and database scripts, but not the business data in your data stores. That means every migrated application needs a period where Appian and the new platform run side by side while data is reconciled. Agree with Appian the last date you can export, how long read access lasts after termination, and whether support extends into the parallel run. Plan the schedule from the contract end backward.

Map data retention and deletion duties

Your records in Appian data stores are your obligation, and so is the deletion you owe when the contract ends. Confirm in the written agreement what Appian deletes, when, and whether it issues confirmation. Check your own retention schedule for records that must be kept longer than the platform holds them, and export those to storage you control before deletion starts.

Decide the target platform

Choose the target before you export packages, because the package contents only describe the design. Flowable provides BPMN, CMMN and DMN engines under Apache 2.0, but the front end, records and interfaces must be built or chosen separately. Operaton and CIB seven are alternatives for teams that mainly need process execution. Document the choice so the export inventory maps to real target components.

Check plug-in and integration ownership

Appian maintains plug-ins at the environment level rather than the application level, so a plug-in may be shared by several applications and is not fully captured by one package. List every plug-in and integration each package depends on, and identify which ones another application still uses. Confirm with Appian which plug-in binaries you are licensed to take out of the environment and whether you may keep running them elsewhere.

Confirm notice and access terms

Read the written contract for the notice period, the renewal mechanism, and what access you keep after termination for export. Confirm whether Appian provides package exports on request, the file size limits for scripts and packages, and any fees for extra exports or extended access. Get the answers in writing, since verbal assurances will not protect a migration deadline.

Verifying that the export is complete

The export is not complete until both the design side and the data side reconcile. Start by comparing the package inventory with the application's object list in Appian. Every process model, record type, interface, decision and integration in the application should appear in the package, along with its import customization file, database scripts, referenced plug-ins and application configuration. Plug-ins are maintained at the environment level rather than the application level, so list them separately and confirm which ones the application actually references. Any object that exists in the application but not in the package is a gap to resolve before you move on.

Next, check the database scripts against the documented limits: individual script files up to 20 MB, up to 100 MB of database scripts per package, and up to 500 packages per application. Confirm these figures against the current Appian documentation for your version, since a package that exceeds a limit will not give you a complete export. Then test-import the packages into a clean environment that matches your target setup, not into the source environment. Record every import error and warning. Keep a checksum for each package file and an export log that records the date, the person who ran the export, the package names and the outcome, so you can show later exactly what was moved.

Design completeness does not prove business data completeness. Records, documents and transactional rows in your data stores stay behind and must be extracted separately. Ask each data owner to agree in writing on record counts per table or entity, and reconcile the extracted counts against the source before you sign off. Use illustrative figures only in your planning, and confirm with the owners which filters, archived records and attachments count as in scope. A migration that passes the package tests but fails the record count reconciliation is incomplete.

How the Appian version changes the export plan

The sequence below confirms where your Appian environments run and how long each version stays supported, so the package export schedule matches the path you can actually take.

Confirm your Appian version and deployment type
Ask the Appian account team or check your administration console for the exact version of every environment, including development, test and production. Record whether each one is Appian Cloud, self-managed on Kubernetes, or self-managed on 25.3 or earlier. Appian's documentation states that from 25.4 self-managed Appian runs only in containers managed by Kubernetes, and 25.3 is the last version that supports non-containerized deployment. Done when you have a table listing each environment, its version and its hosting model.
Map the support dates for each version
Ask Appian for the published support lifetime of your current version and the date its hotfixes end. Appian's AoK FAQ says self-managed environments on 25.3 or earlier keep receiving hotfixes for that version's support lifetime but cannot upgrade to 25.4 or later without moving to Appian on Kubernetes or Appian Cloud. Note that the support window, not the export date, sets your hard deadline. Done when each environment has a written end-of-hotfix date confirmed by Appian.
Choose the upgrade or migration path
For Appian Cloud environments, confirm with Appian how the platform itself is maintained and whether any export runs against the managed service. For self-managed 25.3 or earlier environments, decide between upgrading to Appian on Kubernetes and moving to Appian Cloud, since either route changes the target for your packages. Record the chosen path and the people who approve it. Done when a signed decision names the target platform for each environment.
Set the package export schedule
Only after the version and support dates are confirmed, set the order and timing of package exports. Export from the environment that is closest to the end of its hotfix window first, so you have a complete copy of design objects before any platform change. Plan around the package limits in the topic facts: individual database script files of up to 20 MB, up to 100 MB of database scripts per package, and up to 500 packages per application. Done when you have a dated export calendar reviewed by Appian and your own change board.
Test a package export in a non-production environment first
Run one trial export from a non-production copy of the application and import it into a clean target. Compare the design objects, import customization files, database scripts and referenced plug-ins against the source. Remember that plug-ins are maintained at the environment level, so confirm the plug-in versions on the target separately. Done when the trial import reproduces the application configuration and you have a written list of any gaps.
Record what stays outside the package
Document the items that a package does not carry, most importantly the business data in your data stores, along with any external systems that Appian calls. Assign an owner and a method for each item, such as a database dump or an export from the data store, and schedule it alongside the package export. Done when every data store and integration has a named owner and an export method recorded in the migration plan.

How DeployOpen scopes and delivers an Appian data export

DeployOpen approaches an Appian data export as a written, fixed-scope piece of work inside your own infrastructure. We start from your package inventory and your data stores, then agree in writing what is exported, where it lands and how it is verified before any work begins.

How we scope

Inventory every application and package, with its design objects, import customization files, database scripts and referenced plug-ins.
Check each package against the documented limits: 20 MB per script file, 100 MB of scripts per package and 500 packages per application.
Record the business data in your data stores separately, since packages do not carry it, and agree its export method in the written scope.

How we build

Set up the export tooling and target storage inside your cloud account, data center or air-gapped network.
Export packages and data extracts, then reconcile object counts and checksums against the source inventory.
Test a sample restore or import in a non-production environment and log every gap found, such as plug-ins kept at environment level.

How we hand over

Deliver an inventory register, export runbook and reconciliation report that your team can audit and repeat.
Document what stayed behind, who owns it and what must be rebuilt or migrated in a later phase.
Walk your engineers and compliance leads through the evidence so they can show how the export was controlled.

How we support

Engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts.
Ongoing support, upgrades and continuous testing are available as a retainer if the move spans several phases.
Ask for a written quote based on your scope, and confirm with Appian which export features apply to your version and deployment model.