Business leaders in Switzerland are faced with a major strategic decision when managing IT projects as part of their organisation’s digital transformation: should they prioritise CAPEX or OPEX? In other words, is it better to acquire and develop digital assets (servers, software, infrastructure) through capital expenditures, or to consume IT services via recurring operational expenses?

This structural choice directly impacts financial performance, technological flexibility, company valuation, and even digital sovereignty. In this article, we clarify these concepts and their implications, illustrating them with real-life Swiss business cases and sharing software architecture best practices to help optimise your digital investments.

CAPEX vs OPEX: Key Definitions and Differences

What is CAPEX (Capital Expenditures)?

CAPEX refers to capital expenditures made to acquire or improve long-term assets.

In IT, this includes, for instance, the purchase of servers and hardware, the development of custom software, or the construction of an internal data centre. These expenses are capitalised on the balance sheet and amortised over the life of the asset, meaning the cost is spread over several years. The company becomes the owner of the asset, with all the associated advantages: full control, tailored customisation, and potential long-term value of its technology estate.

However, CAPEX involves a substantial upfront financial commitment, which can significantly impact cash flow. It also requires foresight, as technology assets may become less relevant over time due to evolving business needs and rapid innovation. It is therefore crucial to plan CAPEX carefully, taking into account the asset lifecycle, future upgrades, and the infrastructure’s capacity to evolve over time.

What is OPEX (Operating Expenditures)?

OPEX refers to the ongoing operational expenses required for day-to-day functioning.

In IT projects, this includes subscription-based services, pay-as-you-go cloud resources, monthly software licences, outsourced maintenance, and more. OPEX is recorded as an operating expense in the current year’s income statement. Unlike CAPEX, it does not require a large upfront investment: costs are spread out over time, making IT spending more predictable and easier to track month by month.

This model provides welcome flexibility: services can be scaled up or down as needed, with no long-term financial commitment. For example, rather than purchasing servers, a company may opt to use cloud services billed based on consumption.

However, OPEX also has its drawbacks. Over several years, ongoing payments may exceed the cost of a one-time investment. Moreover, relying on external vendors for critical services creates a dependency that can limit the company’s control over its infrastructure. If the provider experiences operational issues or changes its terms, this can have direct consequences on the client company’s operations.

In summary, CAPEX comes with ownership and upfront effort, while OPEX offers flexibility and smoother cost distribution — each approach has its pros and cons, and it is essential to understand them fully.

Impact on Financial Performance and Company Valuation

The CAPEX vs OPEX decision has a significant impact on a company’s financial statements and on how investors or shareholders perceive its health and value. From an accounting and financial perspective, the treatments differ substantially.

CAPEX expenditures are capitalised, recorded as assets on the balance sheet, and amortised over several fiscal years. This increases the company’s assets and potentially its equity, improving certain financial ratios (such as debt or solvency ratios). On the other hand, if the investment is debt-financed, long-term liabilities also increase.

OPEX expenditures, by contrast, are fully recorded as expenses in the income statement for the current year. They reduce net profit and operating margin in the short term but provide immediate tax relief by lowering the taxable income for that year.

From a cash flow perspective, CAPEX requires a concentrated upfront outlay, whereas OPEX spreads the cost over time, resulting in more predictable cash flows from one period to the next. A company needing to preserve liquidity may lean towards OPEX to avoid a large disbursement, while a cash-rich company may opt for CAPEX to reduce future expenses.

In terms of company valuation, the CAPEX/OPEX structure can influence how long-term value is perceived. CAPEX is often associated with growth investments: analysts assess it to estimate ROI potential and future expansion. For example, a tech scale-up heavily investing in CAPEX to develop proprietary software creates valuable intangible assets (IP, exclusive technology) that can significantly boost valuation in the event of an acquisition or IPO.

Conversely, a highly asset-light company relying heavily on outsourced OPEX functions may show a lean balance sheet and little debt, which can appeal to investors looking for flexibility and variable cost structures. However, excessive reliance on OPEX may also be viewed as a risk (service contracts to renew, lower margins). There’s no universally superior model — it depends on cost structure and industry context.

That said, in challenging economic conditions (e.g., tighter credit access), companies often reduce CAPEX and turn to OPEX-based solutions to minimise funding needs. In contrast, in a growth cycle, they are more inclined to invest in CAPEX to prepare for future scale.

In short, the company’s financial profile (profitability targets, cash constraints, debt strategy) and market expectations (asset-based vs recurring revenue-based valuation) should both be considered when choosing between CAPEX and OPEX.

Technological Flexibility and IT Project Agility

Beyond financial aspects, the CAPEX vs OPEX orientation directly affects a company’s technological flexibility and its ability to execute digital projects with agility.

With a CAPEX model, the organisation owns its infrastructure and software, allowing full control and custom configuration aligned to its specific needs. However, this control often comes at the cost of reduced adaptability: major upgrades may require new investments, and the company can become locked into past technology choices (legacy systems). In contrast, an OPEX approach — typically involving cloud or SaaS solutions — provides much greater elasticity by design. Cloud services allow real-time adjustment of allocated resources (compute power, storage, users), and costs are incurred only for what is actually used. This avoids unused overcapacity and waste, while ensuring immediate availability of additional resources during peak activity.

Moreover, service-based solutions include frequent update cycles — often invisible to the client — meaning the company continuously benefits from the latest features without having to plan complex migration projects every few years. In this sense, OPEX delivers operational agility that is invaluable in fast-changing digital environments.

This technical agility translates into the ability to quickly experiment or seize new digital opportunities. For example, rolling out a new analytics tool or mobile app for a pilot project is easier under an OPEX model (monthly subscription, quick setup) than under a CAPEX model, which would require upfront infrastructure deployment. As one expert puts it, “on-demand cloud services bring inherent benefits in eliminating waste, providing elasticity and, perhaps most importantly, enabling agility.” The pay-as-you-go model allows businesses to test, scale, and switch services as needed, giving them the responsiveness to act on market trends. This flexibility is central to digital transformation and continuous innovation.

However, the agility advantage of OPEX must be weighed against the technological dependency it creates. Choosing a SaaS solution or public cloud means ceding a level of control to a third-party provider: the company becomes subject to their release cycles, roadmap decisions, pricing policies, and even business strategy shifts. In contrast, a CAPEX model — especially one built on open-source technologies and custom development — allows full strategic independence. The code is owned, fully customisable, and free from external licensing or roadmap constraints. This level of control is especially important for Swiss companies seeking to build sovereign, sustainable digital assets tailored to their business needs and regulatory landscape.

For example, several Swiss banks have historically favoured custom-built proprietary systems, ensuring compliance, deep integration with their core IT, and exceptional stability. This CAPEX choice delivered long-term robustness, even if it sometimes limited short-term agility. In truth, it wasn’t the CAPEX model that hindered innovation, but often a lack of modularity or forward-looking architecture. Today, with modern design approaches (API-first, microservices, open-source stacks), it’s entirely possible to build modular, evolutive CAPEX solutions that offer both independence and adaptability.

In practice, the most successful companies combine both models wisely: they invest in a robust, custom or open-source software foundation to secure strategic control over core functions, and complement it with cloud or SaaS services to speed up the deployment of non-differentiating or experimental features. This hybrid architecture brings together agility, sovereignty, and budget efficiency.

Digital Sovereignty, Compliance, and Model-Related Risks

In Switzerland, digital sovereignty and regulatory compliance are key strategic considerations in the CAPEX vs OPEX decision — especially when sensitive data is involved.

Choosing a CAPEX model often means keeping data “in-house,” on servers that are physically or legally owned by the organisation (or at the very least, by a trusted local provider). This is frequently driven by confidentiality and regulatory requirements: certain types of data (such as in healthcare or finance) may legally be prohibited from leaving Swiss territory or must remain under Swiss jurisdiction. By investing in its own infrastructure or a local private cloud, a company ensures that its information is hosted in Switzerland, governed by Swiss law, and protected from foreign interference.

In contrast, relying on OPEX solutions from global providers (e.g., American hyperscalers like AWS, Microsoft Azure, or Google Cloud) can raise concerns around data protection and exposure to foreign laws (such as the US PATRIOT Act, Cloud Act, etc.). This is one reason why the Swiss Confederation is actively working on a sovereign cloud project: the Swiss Government Cloud, with an investment budget of CHF 320 million, aims to create a reliable, secure, and sovereign national cloud infrastructure to complement existing public cloud services. This public investment — which we will explore further in the next section — is motivated by the desire to reduce dependency on foreign providers and maintain control over government data. “It’s an investment in the future that strengthens sovereignty,” the Finance Minister stated when presenting the project. The Swiss Parliament has explicitly required that this sovereign cloud prioritise open standards, open-source software, and vendors headquartered in Switzerland, to maximise the country’s technological autonomy. This case illustrates how a major CAPEX-driven initiative (building one’s own infrastructure) can be justified by sovereignty concerns.

From a risk standpoint, each model carries its own pitfalls. A poorly scoped CAPEX investment can result in underused or outdated assets that weigh down the balance sheet (both financially and technically). Moreover, internalising services requires having the right in-house expertise to operate and secure them over time — which can be challenging in the absence of sufficient IT talent, creating operational risks. On the other hand, a fully OPEX-based model exposes the company to supplier dependency: if the provider sharply increases pricing, changes its service offering, or suffers a major outage, the client organisation may be directly impacted with no fallback.

It is therefore essential — particularly for Swiss mid-sized and large organisations handling critical data (banks, insurers, hospitals, public institutions) — to carefully assess the legal and operational risks tied to cloud services and outsourcing. Often, hybrid solutions or contractual safeguards are implemented to mitigate these risks (e.g., selecting clouds with data centres located in Switzerland, encrypting data, including reversibility clauses to repatriate data internally if needed, etc.).

In summary, digital sovereignty is now a decisive factor that can push companies toward greater CAPEX (to maintain local control), or toward carefully selected OPEX options (Swiss providers, private cloud) that guarantee an appropriate level of trust. Each organisation must weigh the sensitivity of its data and systems: which workloads can be hosted in a public external cloud, and which must remain secured within a tightly controlled perimeter?

In the next section of this article, we’ll look at concrete examples of CAPEX, OPEX, and hybrid strategies in Switzerland, as well as best practices to help you adopt an optimal structure for your digital projects.

{CTA_BANNER_BLOG_POST}

Real-World Examples of CAPEX, OPEX, and Hybrid Strategies in Switzerland

To ground these concepts in reality, let’s examine several Swiss use cases that illustrate different approaches — CAPEX, OPEX, or hybrid — along with their respective advantages and limitations.

Swiss Government Cloud: A CAPEX Investment in Public Sovereignty

A flagship example of a full-CAPEX strategy is the Swiss Government Cloud (SGC) — the sovereign cloud initiative launched by the Swiss Confederation. Faced with the sovereignty concerns discussed earlier, the Swiss government has opted to invest heavily in building a national cloud infrastructure dedicated to public administration. The Federal Office of Information Technology (FOITT) will lead this programme from 2025 to 2032, with the goal of establishing a hybrid multi-cloud platform serving federal needs while also being available to cantonal and municipal administrations.

The approach is clearly CAPEX-driven: the project involves creating a long-term infrastructure asset (data centres, software platforms) owned by the state. The expected benefits include greater independence from global cloud giants, local jurisdiction over sensitive government data, and a cost-price shared service offering for the entire public sector.

This choice enables full end-to-end architectural control: for example, emphasis is placed on using open technologies and Swiss-based vendors to avoid vendor lock-in. The limitations, however, lie in cost and complexity: mobilising hundreds of millions in funding and highly specialised talent over several years carries risks of budget overruns or partial obsolescence by the time the platform is fully operational — especially as the public cloud market continues to evolve rapidly.

Additionally, despite its ambition, the sovereign cloud will not offer the full spectrum of services available from hyperscalers — it is designed as a complement for critical workloads rather than a complete replacement of public cloud solutions. In short, this case reflects a deliberately CAPEX-oriented strategy driven by sovereignty and long-term vision, while also highlighting the significant governance challenges it entails.

UBS and Microsoft Azure: An OPEX Bet on Cloud Agility in Banking

Some Swiss companies favour an OPEX approach to boost their technological agility. UBS, one of the world’s largest private banks, adopted a “cloud-first” strategy as early as 2018 in partnership with Microsoft. By 2022, after migrating one-third of its applications to Azure, UBS announced plans to raise that figure to 50% by 2027 — including critical workloads. The goal: to accelerate the rollout of digital banking services, reduce fixed infrastructure costs, and lower the bank’s carbon footprint through more energy-efficient data centres.

According to UBS, the public cloud has helped halve certain production deployment cycles and enabled the faster launch of digital MVPs thanks to on-demand infrastructure. The integration of carbon impact tracking modules, co-developed with Microsoft, further illustrates how the OPEX model supports ESG commitments.

That said, such externalisation raises crucial issues for a systemically important bank: FINMA compliance, data residency (using Swiss or European cloud regions), continuous security audits, and robust reversibility clauses. UBS had to negotiate a strict contractual framework ensuring data confidentiality, resilience, and governance.

This case illustrates a broader trend: even traditionally CAPEX-heavy sectors like banking are now embracing cloud-based OPEX models for strategic projects — provided the associated risks are tightly managed.

The Hybrid Model: Combining CAPEX and OPEX for the Best of Both Worlds

Between the two extremes, most Swiss companies adopt a hybrid model that blends targeted CAPEX investments with smart OPEX usage.

According to a recent study, 56% of Swiss businesses using cloud services have also kept local servers — clear evidence that more than half are adopting a hybrid approach that combines cloud and on-premise infrastructure. This combination allows them to leverage the advantages of both models while compensating for their respective limitations. In practice, organisations typically allocate CAPEX to components they want to fully control or amortise over time, and OPEX to resources or applications where flexibility and scalability are key.

A typical example: a Swiss industrial company might keep its critical production management system running on dedicated servers (CAPEX) to ensure confidentiality and uptime, while using SaaS tools for support functions such as HR or CRM (OPEX). Similarly, a Swiss hospital may host its patient database on secure, in-house machines (CAPEX) to comply with data protection laws, while relying on cloud services for non-sensitive data analytics or logistics management (OPEX). This hybrid approach provides peace of mind for mission-critical systems, and agility for less sensitive workloads.

Cost optimisation is also a strong driver: savvy companies often invest in CAPEX for their baseline needs (steady and predictable workload levels) and use cloud-based OPEX solutions to handle peak loads or temporary projects. This strategy avoids overprovisioning: they own only what’s needed to cover the core, and scale flexibly through the cloud as demand spikes. In other words, CAPEX supports the “run”, and OPEX handles the “change” or the exceptional.

Best practices observed in this hybrid approach include a strong emphasis on interoperability: internal systems and external services must coexist seamlessly. This requires well-designed architectures (see next section) and clear governance. One common pitfall is turning hybrid into the sum of both models’ drawbacks — for example, by duplicating costs through redundant resources (overprovisioning on-premise while also paying for unnecessary cloud capacity), or by allowing technical complexity to spiral. However, with proper management, many Swiss companies find that a hybrid CAPEX/OPEX strategy is the most efficient and resilient approach to support long-term digital transformation.

Software Architecture Best Practices to Optimise Investment

Whether favouring CAPEX, OPEX, or a mix of both, how systems are architected plays a crucial role in the success of the chosen model.

A modern software architecture can enable an optimal investment structure by reducing reliance on any one irreversible choice. Here are several expert-recommended best practices:

API-First Approach and Open Architectures

Designing applications and services with APIs (Application Programming Interfaces) from the outset provides great flexibility.

It enables seamless integration between internal components and external services. For example, a business application developed in-house can consume cloud-based microservices via standard APIs — or vice versa, a SaaS solution can be swapped for another if the APIs are compatible. API-first avoids vendor lock-in and makes it easier to switch providers — invaluable when relying on OPEX services.

Additionally, by standardising interfaces, companies can transparently combine CAPEX and OPEX modules within their IT systems. Interoperability is key: it preserves strategic agility and keeps options open — whether to internalise a service if OPEX costs spiral, or to outsource if reducing CAPEX becomes a priority. The Swiss Confederation has taken this to heart, advocating for open standards in its sovereign cloud initiative — a recommendation relevant to all organisations.

Leveraging Open-Source Software

Open source is a powerful ally for maintaining control over your digital strategy while optimising costs.

By choosing proven open-source solutions (operating systems, databases, middleware, etc.), a company can reduce licensing costs (OPEX) and avoid dependence on a single vendor. Of course, “free” open source is a myth: CAPEX is still required to build internal expertise or bring in service providers to install, customise, and maintain the software. But this builds in-house knowledge capital and opens the door to collaboration with open-source communities for continuous improvement.

Moreover, open-source software provides transparency, especially in terms of security and compliance — the source code can be audited and strengthened if needed. Many Swiss organisations already combine open source and digital sovereignty: for instance, FOITT prioritises open source in the Swiss Government Cloud, and some Swiss banks self-host sensitive data in open-source databases to avoid foreign vendor lock-in. In this sense, open source is a CAPEX investment (integration time) that reduces recurring OPEX (licenses, royalties) and ensures long-term independence.

Modular Architecture and Microservices

A modular architecture breaks systems down into independent (or loosely coupled) components — ideally implemented as microservices in modern software ecosystems.

Each module serves a distinct function and communicates with others via standard interfaces. This modularity offers several benefits in optimising CAPEX and OPEX. First, it allows for per-component investment decisions: a company may choose to internally develop (CAPEX) a core module that delivers a unique competitive advantage, while using a SaaS solution (OPEX) for a generic module like payroll or email.

If modules are well-isolated, having one in OPEX doesn’t compromise the performance of those built in CAPEX, and vice versa. Second, modularity supports future evolution: if one module becomes obsolete or too expensive, it can be replaced without reengineering the entire system. For example, in a modular e-commerce architecture, you could swap payment providers (OPEX) without touching the product catalogue (CAPEX) or the rest of the platform.

This flexibility protects past investments and avoids the domino effect. “Design for change” becomes the guiding principle: companies anticipate that some components may migrate from cloud to on-prem or vice versa, depending on future needs. On an operational level, technologies like containerisation (Docker, Kubernetes) support this portability — the same container can run on internal VMs or public cloud environments, giving businesses the freedom to move workloads based on cost or compliance.

By adopting a modular, scalable, and resilient architecture, companies can continuously fine-tune their CAPEX/OPEX mix instead of being locked into a fixed structure.

In conclusion, these architectural best practices — API-first, openness, open source, modularity — are designed to minimise the constraints of any given investment model. They serve as a hedge against lock-in: even if today your infrastructure is predominantly OPEX-based in the cloud, you retain the ability to bring certain components back in-house as CAPEX tomorrow (or to switch providers) without rebuilding everything. Conversely, if you’ve heavily invested in CAPEX, an open modular architecture makes it easy to integrate new cloud services when it makes sense — extending the lifecycle and value of your assets.

These are agile architectural principles aligned with financial strategy, ensuring your digital infrastructure continues to serve evolving business needs over time.

Conclusion: Discuss Your Situation with a Digital Ecosystem Expert

The CAPEX vs OPEX dilemma goes far beyond accounting — it’s a true strategic lever for Swiss companies seeking performance, flexibility, and digital sovereignty. As we’ve seen, this decision affects a company’s financial structure, capacity for innovation, long-term valuation, and level of technological dependency. There is no one-size-fits-all answer: each organisation must define its own balance based on business realities, budgetary constraints, and digital ambitions.

In practice, hybrid approaches — combining long-term investments with on-demand services — are emerging as sustainable, agile solutions. But only if they’re carefully architected. Indeed, it’s the software architecture — modular, open, and scalable — that makes it possible to implement a CAPEX/OPEX strategy aligned with business goals.

At Edana, we design custom digital ecosystems that embed these principles from the ground up. By guiding executives and IT leaders through the technical and financial trade-offs, we help build solutions that are robust, scalable, and cost-effective.

Let’s discuss the best structure for your next digital project — and turn your IT investments into a sustainable driver of business performance.

Discuss about your challenges with an Edana expert