Getting an app from development into the hands of business users sounds straightforward—but anyone who has done it manually knows how quickly things can go wrong. A missed dependency, a skipped approval step, or direct access to a production server can bring your entire reporting environment to a halt. Understanding the deployment steps in a structured software deployment process is the first move toward making releases faster, safer, and more predictable.
Whether you work with Qlik Sense, Power BI, SAP BusinessObjects, or any other BI platform, the same core principles apply. This article walks through the five steps of the deployment process, explains where version control and automation fit in, and helps you build a release management approach that holds up under pressure.
What is software deployment and why does it matter?
Software deployment is the process of moving an application from a development environment into a production environment where end users can access it. It includes every step between finishing development and making the app available—packaging, testing, approving, publishing, and verifying. Done well, it keeps production stable and users productive. Done poorly, it introduces errors, downtime, and lost trust.
In a BI context, the stakes are especially high. Business users rely on dashboards and reports to make decisions. If a faulty app reaches production, or if a dependency like a QVD file or extension is missing, users can’t do their jobs. The deployment process is not just a technical handoff—it is a quality gate that protects the reliability of your entire data environment.
Many organizations underestimate how many steps are involved in application deployment. It is not just copying a file from one server to another. You need to account for reload tasks, data connections, extensions, permissions, and the relationships between apps. Without a clear process, each deployment becomes a unique, risky event dependent on the knowledge of a single person.
What are the 5 steps of the deployment process?
The five steps of the software deployment process are: plan, develop and test, stage, approve, and deploy to production. Each step serves a specific purpose in moving an application safely from idea to live environment. Skipping any step increases the risk of errors, inconsistencies, or outages reaching your end users.
Step 1: Plan
Planning defines what is being deployed, why, and when. This includes identifying which apps, tasks, extensions, or data files are part of the release and understanding the dependencies between them. A deployment without a clear plan often results in incomplete releases where some components are updated and others are not, breaking the working set.
Step 2: Develop and test
Developers build or modify the application in a dedicated development environment. Testers then validate the changes against expected behavior. Change tracking at this stage is especially useful—when you can see exactly what changed between versions, testing becomes focused rather than exhaustive. You test what changed, not everything.
Step 3: Stage
Staging replicates the production environment as closely as possible. You deploy the application to a staging server and run final checks. This is where data connections, reload tasks, and dependencies are verified before anything touches production. A staging step catches environment-specific issues that development testing cannot surface.
Step 4: Approve
Before anything reaches production, someone with authority must sign off. Enforced approval workflows ensure that only reviewed and validated apps move forward. In regulated industries, this approval step is not optional—it is part of compliance. Approval should be documented, traceable, and tied to a specific version of the application.
Step 5: Deploy to production
The final step moves the approved application into the live environment. In a well-structured deployment pipeline, this step is automated and controlled. No individual developer should need direct access to the production server. The deployment tool handles the promotion, updates data connections, and confirms that all dependencies are present and correct.
How does version control fit into the deployment steps?
Version control is the foundation that makes every deployment step reliable. It tracks every change made to an application, stores previous versions, and allows teams to restore a working state in case something goes wrong. Without version control, you cannot confidently compare what changed, roll back a failed release, or understand the history of an app.
In the development and testing phase, version control gives testers a clear picture of what changed between the current version and the last approved one. This shortens test cycles significantly because testers focus only on the delta rather than retesting the entire application. It also supports collaboration—multiple developers can work on the same app without overwriting each other’s changes.
During the approval and deployment steps, version control ensures that the exact version reviewed and approved is the one that gets deployed. There is no ambiguity about which state of the app is in production. And if a problem appears after deployment, restoring the previous version becomes a straightforward action rather than a manual reconstruction effort.
Version control also supports data lineage—knowing which QVD files, expressions, and variables an app depends on. When a data source changes, you can trace the impact across all apps that use it before deploying any update. This kind of dependency insight is what separates a mature deployment process from an ad hoc one.
What is the difference between manual and automated deployment?
Manual deployment requires a person to carry out each step—copying files, updating connections, configuring tasks, and publishing apps—directly on the server. Automated deployment uses a tool or pipeline to execute these steps consistently, without human intervention on the production server. The key difference is reliability: automation does the same thing every time, while manual processes introduce variability and risk.
Manual deployment has several practical problems. It is time-consuming, especially when an app has multiple dependencies that also need to be promoted. It requires individuals to have direct access to production servers, which creates a security and governance risk. And because each person may follow a slightly different process, the outcome is inconsistent. Some customers report spending six hours or more deploying a single app manually.
Automated deployment removes the person from the equation at the production level. The deployment tool executes a predefined, tested process. Settings are saved, so after the initial setup, each subsequent deployment runs with minimal clicks. Data connections are updated automatically, dependencies are verified, and the production environment remains consistent.
For BI teams in particular, automation also means that business users experience zero disruption during a deployment. A new version of an app can be published in the background while users continue working. That kind of reliability is difficult to achieve with manual processes, where a mistake during deployment can take down access for everyone.
How do you ensure compliance during the deployment process?
Compliance during the deployment process requires enforced approval workflows, full audit trails, and controlled access to production environments. Every deployment should be traceable—who approved it, which version was deployed, when it happened, and what changed. Organizations subject to regulations like HIPAA or Sarbanes-Oxley need this documentation as evidence of controlled, governed processes.
The approval step in the deployment pipeline is where compliance is either built in or bypassed. If developers can publish directly to production without a review, there is no governance. Compliance-driven deployment requires that only reviewed and approved versions reach the production environment and that this approval is recorded against a specific version of the application.
Access control is equally important. When individual team members have direct access to production servers, it becomes difficult to enforce consistent processes or maintain a clean audit trail. A better approach is to restrict production access to the deployment tool itself, so all changes flow through a controlled, logged channel.
Release management adds another layer of compliance support. By grouping related apps into a single release, you ensure that interdependent components are always deployed together. This prevents situations where one app is updated but its dependencies are not, which can cause data inconsistencies that are hard to trace and explain to auditors.
What tools support a structured deployment process?
A structured deployment process needs tools that handle version control, workflow enforcement, dependency management, and automated promotion. For general software development, tools like Git and CI/CD pipelines are common. For BI environments, the tooling needs to understand BI-specific assets—apps, reload tasks, extensions, data connections, and QVD files—which general-purpose DevOps tools do not handle natively.
BI teams often try to adapt GitHub or similar tools for their deployment needs, but these solutions were not built for BI assets. They can manage scripts and code, but they do not understand the relationships between a Qlik app and its reload tasks, or between an SAP BusinessObjects universe and the documents that depend on it. This forces teams to build workarounds or accept gaps in their governance.
The right tool for a BI deployment pipeline should support the full application lifecycle—from version control and change tracking through approval workflows, dependency visibility, and automated promotion across environments. It should work across on-premises, hybrid, and cloud setups, and it should not require developers to have direct access to production servers.
How PlatformManager supports every step of the deployment process
We built PlatformManager specifically to solve the deployment challenges that BI teams face every day. It covers the entire application deployment lifecycle for Qlik Sense, Qlik Cloud, QlikView, Power BI, and SAP BusinessObjects—from version control to automated promotion to production. Here is what that looks like in practice:
- Integrated version control — every version of your app, task, extension, or data file is stored and retrievable, with restore available in just two clicks
- Change tracking — see exactly what changed between versions so testers can focus their effort and reduce cycle times
- Dependency management — full visibility into which QVDs, extensions, and tasks your apps depend on, so nothing is missing when you deploy
- Enforced approval workflows — only reviewed and approved apps reach production, with a full audit trail for compliance requirements like HIPAA and Sarbanes-Oxley
- Automated deployment — no developer needs direct access to production; we handle promotion automatically, updating data connections and verifying dependencies along the way
- Release management — group related apps into a single release to keep your production environment consistent and restorable as a working set
- Hybrid and multi-tenant support — deploy across on-premises and Qlik Cloud environments, including multi-tenant setups, without changing how your team works
Over 200 companies already use PlatformManager to make their deployment process faster, safer, and more reliable. The best way to see whether it fits your environment is to try it yourself. Start a free three-day trial with full access to a cloud server and a demo collection of apps and data—no risk, no commitment, just a clear picture of what structured deployment can look like for your team.