Application migration is a critical part of building and maintaining solutions on the SpreadsheetWeb platform. As organizations expand their models, update calculation logic, and refine user interfaces, the ability to safely promote applications across Development, QA, and Production environments becomes essential. SpreadsheetWeb provides a structured migration framework, supported by DES exports, environment controls, transactional version history, and ALM tools, to ensure that upgrades remain smooth, predictable, and fully aligned with enterprise requirements.
Introduction to Application Migration on SpreadsheetWeb
On SpreadsheetWeb, migrating an application means promoting it from one environment to another using a DES file. This process ensures that enhancements or fixes introduced in development can be tested and validated before reaching end users. Migration is also tightly connected to SpreadsheetWeb’s built-in version control system, which records every “transaction” each time an application is published.
A transaction represents an application publication event, essentially a snapshot of the application at a specific moment in time. These transactions are stored in the platform and can be viewed, compared, or downloaded at any time. Transaction History gives teams a reliable rollback option, enabling them to revert an application to a prior version if needed. Together, migration and transactional version history form the backbone of SpreadsheetWeb’s Application Lifecycle Management strategy.
Preparing for Migration
Before exporting a DES file, teams should ensure that the application version is stable, consistent, and ready for promotion. This involves reviewing UI components, calculation logic, workflows, and any integration points. Preparation also includes examining database changes.
Unlike many platforms, SpreadsheetWeb embeds the entire database schema directly into the DES file. As a result, the DES contains not only the application settings but also all table and field definitions. When imported into a new environment, the application’s entire schema is created automatically. When updating an existing application, the schema is updated to match the new version.
Because the DES import process applies schema changes, reviewing recent transactions before migration is important. Transaction history allows the development team to confirm what changed, identify differences between versions, and ensure that no unintentional modifications are being propagated to production.
Migration Process Overview
The migration workflow remains straightforward: export the DES file from the source environment, then import it into the target environment. The DES file includes the UI, formulas, scripts, workflows, and full database schema. After import, the target environment reflects the exact structure of the migrated application.
For existing applications, schema changes are applied automatically. SpreadsheetWeb is designed to preserve existing data as long as the changes remain backward compatible. Additions to the schema, such as new columns, pose no risk to older records. Only breaking changes, such as removing or renaming fields used by previous versions, may require additional handling.
If such changes are unavoidable, SpreadsheetWeb provides a separate Data Export/Import mechanism that allows teams to migrate or transform saved records after updating the application structure. This ensures flexibility: organizations can migrate only the application, only the data, or both, depending on business needs.
Another important safeguard in this process is transactional version control. Every time an application is published, SpreadsheetWeb automatically stores a new transaction. If a migration introduces unintended behavior, teams can download or restore a previous transaction and revert the application to a known stable version. This rollback capability significantly reduces migration risk and supports safe iteration across environments.
Post-Migration Testing & Validation
After importing the application, thorough validation ensures that the migration is successful. Teams should confirm that calculations, UI rules, and workflows function correctly in the target environment. For applications using databases, testing must also include loading existing records and saving new ones to verify backward compatibility.
If issues arise, the development team can use the Transaction History feature to compare the migrated version with previous transactions and identify where changes may have been introduced. The combination of structured migration and transactional rollback offers a reliable safety net during the release cycle.
Best Practices for Application Lifecycle Management
SpreadsheetWeb recommends the following best practices to ensure smooth migrations and long-term application reliability:
-
Use dedicated Dev, QA, and Prod environments to isolate development work from live operations.
-
Promote applications using DES files—never modify production applications directly.
-
Review Transaction History before migration to understand recent changes and maintain a clear audit trail.
-
Take advantage of built-in rollback capabilities, using transactions as restore points when needed.
-
Maintain consistent database schemas across environments to ensure seamless load/save operations.
-
Avoid breaking schema changes unless legacy data has been handled or archived.
- Use the Data Export/Import tools to migrate or synchronize saved records separately from the application.
-
Keep regular DES snapshots as part of your backup and release management strategy.
These practices align with SpreadsheetWeb’s ALM framework and help organizations deliver improvements predictably while minimizing risk.
Conclusion
SpreadsheetWeb provides a powerful and flexible migration framework that combines DES-based application promotion, automatic schema synchronization, independent data migration tools, and built-in transactional version control. Because every publication is stored as a transaction, teams always have a reliable way to revert to earlier versions, greatly reducing the risk of unintended changes. By following ALM best practices and leveraging these platform capabilities, organizations can evolve their applications smoothly while maintaining a stable, high-quality production environment.
