_{No time to read? Listen to the podcast:}

(Prefer videos? Watch a summary of this article below.)

A headless Umbraco multi-site setup can reduce duplicated content and maintenance across related websites, but it also concentrates operational risk in a shared CMS. The architecture works best when brands or regions use similar content structures and can agree on how their platform evolves.

For business leaders, the decision extends beyond hosting costs. A shared installation may help a manufacturer launch regional websites faster, yet make an independently operated subsidiary wait for a common upgrade. Understanding that exchange is essential before consolidating a digital portfolio.

What Is a Headless Umbraco Multi-Site Setup?

A headless Umbraco multi-site setup uses one Umbraco content management installation to supply several websites through APIs. Editors manage content centrally, while separate frontend applications control how visitors experience each website.

This article focuses on Umbraco CMS with its Content Delivery API, available in self-hosted and Umbraco Cloud deployments. Umbraco Heartcore is a separate managed headless offering; its commercial terms and operational responsibilities require their own assessment. 

Here, “single instance” means one logical CMS installation and content database. That installation can run across multiple application servers, so consolidation does not necessarily mean relying on one machine.

How Does a Single-Instance Multi-Website Architecture Work?

A shared Umbraco backend stores and publishes content, while each frontend retrieves the material intended for its audience. Clear ownership of content, routing, and delivery keeps those websites distinct. 

Shared content management backend

Umbraco typically represents each website with a separate root node in its content tree. These roots share the installation’s database and schema definitions, although individual websites can use different document types. A central team should therefore own changes to shared structures. 

Separate frontends and delivery channels

Websites sharing an Umbraco backend can have their own frontend technology, hosting, and release process. For example, a corporate website could use Next.js while a partner portal uses another framework. Both consume Umbraco content, but their navigation, accessibility, and user journeys remain application responsibilities. 

Content APIs and website routing

The Content Delivery API returns structured content rather than finished web pages. Its Start-Item header identifies a root for content operations, helping resolve identical paths across websites. Developers must map each frontend domain to the correct site context and handle redirects, canonical URLs, and sitemaps. 

When Does Running Multiple Websites in One Instance Make Sense?

A shared Umbraco installation makes sense when websites have substantial common content, compatible operating requirements, and a team accountable for the whole platform. Useful candidates include:

• Regional websites sharing product information and corporate messaging.
• Related brands using common content models and integrations.
• Franchise websites with centrally managed material and local details.

Umbraco’s OG Clean Fuels case study illustrates centralized headless delivery: one environment supports a website, customer portal, and mobile app, with content available in five languages. The example shows the value of sharing information across channels that serve the same business.

What Are the Benefits of Headless Umbraco Multi-Site?

The pros of headless Umbraco include: centralized content governance, shared components and content reuse, consistent branding, lower infrastructure and maintenance costs, faster website launches, easier updates and integrations. The benefits grow when websites share meaningful requirements and teams deliberately maintain reusable assets. 

Centralized content governance

A shared Umbraco backoffice gives content governance a common administrative foundation. User groups, start nodes, and granular permissions can limit which material editors access. Headquarters can control corporate information while regional teams manage local pages, provided ownership and approval rules are defined. 

Shared components and content reuse

Reusable Umbraco content models let several websites reference the same approved information. A manufacturer could maintain one equipment description and reuse it across regional catalogs. Frontend components can also be shared through a component library, although that requires separate engineering and does not happen automatically through Umbraco. 

Consistent branding across websites

A shared Umbraco content model helps keep brand images and messaging consistent/standardized across websites. A shared frontend design system keeps fonts and page elements looking and working as intended. At the same time, it allows changes for local markets. Before letting local teams make changes, decide which choices must stay with the brand team. 

Lower infrastructure and maintenance costs

When you consolidate websites via headless Umbraco multi-site, you naturally reduce the number of CMS installs that you need to host, monitor, patch and backup. Savings depend on capacity requirements and support workload. Include separate costs for frontend hosting, commercial add-ons, regression testing and resilience measures when considering total ownership costs.

Faster website launches

A new Umbraco website can reuse established content models, integrations, and editorial conventions. For a regional rollout, much of the remaining work may concern localization, domain setup, content preparation, and frontend configuration. The advantage diminishes when the new website requires fundamentally different workflows or functionality.

Simplified updates and integrations

A shared Umbraco backend can reduce duplicated integration development. For example, one maintained connection to a product information management system can supply several brand websites. Keep source ownership explicit: Umbraco can manage editorial descriptions while commerce and ERP systems retain responsibility for transactions and operational data.

What Are the Drawbacks of Using a Single Instance?

A single installation means shared points of failure, performance and scalability limitations, more complex permissions and editorial workflows, deployment dependencies, limited technology autonomy, and the increasing architectural complexity. As you see, headless delivery separates presentation, but it does not remove those backend dependencies.

Shared points of failure

A database outage, faulty CMS deployment, or compromised administrative account can affect every connected website. Cached pages may remain available, but publishing and uncached content requests can still fail. Recovery planning must account for the combined business impact across the portfolio.

Limitations of performance and scalability

Websites in one Umbraco installation share backend capacity. A resource-intensive API query or large publishing operation can affect other sites, even when their frontends are hosted separately. Capacity planning should consider aggregate demand and simultaneous peaks, not simply counting websites.

Complex permissions and editorial workflows

Umbraco permissions become harder to maintain as regional teams, agencies, and brand owners overlap. An editor may need access to local pages and shared campaign assets without authority to change global messaging. Test representative user roles and publishing scenarios before adding more teams.

Deployment dependencies

Changes to shared Umbraco schemas can require coordinated frontend releases. Renaming a field used by several applications, for example, may break consumers that still expect the old response. Backward-compatible changes and API contract tests reduce this risk, but coordination remains part of the operating model.

Limited technology autonomy

Each frontend can choose its own framework, while the shared backend runs a common Umbraco version and compatible package set. One brand cannot independently upgrade that CMS installation. Businesses with separate technology roadmaps should consider whether this constraint will delay necessary changes.

Increasing architectural complexity

Umbraco sites are different, and exceptions are made for the brand. Shared models get bloat with optional fields, and routing and integrations get conditional rules. Watch how much customization each extra website needs. If the drift continues for long enough, it might be worth moving selected sites to separate installations.

How Does a Single Instance Compare With Separate Umbraco Instances?

A single instance favors coordinated reuse. Separate instances give greater operational independence. The comparison assumes separate installations have appropriately separated infrastructure and access controls.

Separate instances can still reuse code. Umbraco Cloud Baselines allow projects to inherit common components and receive shared updates; Umbraco’s multisite guidance recommends considering Baselines on Cloud. This provides a practical alternative when reuse matters but a shared database is undesirable. 

“Before recommending one Umbraco instance, I’d look at what the websites actually share. Similar content models and integrations give you a useful foundation. If every brand needs exceptions, however, the time spent coordinating changes can eat into the savings you expected.”

— Vadim Birkos, Senior Full-Stack .NET and Sitecore Developer at SaM Solutions

What Security and Data Isolation Risks Should Be Considered?

Multiple content roots provide organizational separation, not a complete security boundary. A shared Umbraco database and administrative environment require explicit controls wherever brands or business units need restricted access.

Backoffice permissions and API authorization solve different problems. Umbraco’s enabled Delivery API is publicly accessible by default unless configured otherwise. Consequently, a frontend’s site filter should not be treated as enforced tenancy isolation, meaning separation of each site’s data and access. Test cross-site content requests directly, and protect preview credentials on the server.

Isolation reviews should cover media URLs, search indexes, logs, backups, and integration credentials as well as pages. Where contractual requirements demand stronger separation, assess separate databases and infrastructure. In ecommerce deployments, keep sensitive customer and payment information in systems designed and governed for those records.

How Can Performance and Scalability Be Managed?

Performance depends on efficient API queries, appropriate caching, and capacity matched to measured workloads. Independent frontend hosting and load balancing can expand delivery capacity, while the shared CMS database and storage still require monitoring and capacity planning.

Caching can materially change backend demand. As an illustrative calculation, if an edge cache serves 95% of 1,000 eligible content requests per second without contacting the origin, 50 requests reach the CMS. That calculation excludes revalidation and other workloads; it is not an Umbraco benchmark.

Load tests should include cold caches, publishing activity, and overlapping campaigns. Umbraco’s Delivery API documentation specifically cautions against hiding slow uncached queries behind caching. Fix expensive queries and content structures before treating extra servers as the answer.

What Are the Best Practices for Headless Umbraco Multi-Site Architecture?

To create a reliable multi-site architecture with Umbraco, you should define clear content boundaries, design reusable content models, separate frontend deployments, plan caching and API delivery, establish governance and access controls, and finally monitor each website independently. 

Define clear content boundaries

Give every website an identifiable root and distinguish local content from genuinely shared records. Define who can change shared information and which websites consume it. Avoid cross-site references that make a brand difficult to migrate or retire later.

Design reusable content models

Share models when their meaning and lifecycle match across websites. A common office-address model may work well; distinct regional pricing rules may not. For localization, define language variants, fallback behavior, translation ownership, and which fields must remain market-specific.

Separate frontend deployments

Give each frontend its own release pipeline, rollback process, and compatibility checks. A visual update should not require deploying every website. Coordinate shared API changes through an agreed transition period so existing consumers continue working during migration.

Plan caching and API delivery

Make sure that cache rules distinguish website, language, and other response-changing inputs. Keep preview and personalized responses out of shared public caches, and define how publication invalidates stale material. CMS output caching and external CDN caches need coordinated policies.

Establish governance and access controls

Assign ownership of the platform, limit administrative access and review access when roles change. Document who is responsible for approval of global and local content. More complex approval processes may require Umbraco Workflow or other implementation, so budget for governance capabilities explicitly.

Monitor each website independently

Measure availability, API latency, errors, and cache effectiveness per website. Portfolio-wide averages can conceal a struggling brand. For ecommerce, include customer actions such as product discovery and checkout handoffs, so operational reporting reflects the experience visitors actually receive.

“Each team can have its own frontend and release schedule, but the shared CMS still ties the websites together. Rename a field that another team uses, and their site can break. SaM Solutions’ Umbraco experts track those dependencies and agree on who owns the shared models. That makes it much clearer what needs testing before a change goes live.”

— Vadim Birkos, Senior Full-Stack .NET and Sitecore Developer at SaM Solutions

How Do You Decide Whether This Architecture Is Right for Your Business?

Choose the architecture by comparing content overlap, operational ownership, and isolation requirements. Use the questions below to identify constraints before estimating savings.

Validate the decision with two representative websites, including the more demanding one. Compare three-year hosting, engineering, support, and migration costs, then test publishing and recovery scenarios. A small hosting saving should not outweigh an unacceptable outage or governance constraint.

What Is the Final Verdict on Running Multiple Websites in One Instance?

Headless Umbraco multi-site is a good option for related websites that benefit from shared content and shared ownership of the platform. When independent upgrade schedules, strict isolation or divergent requirements dominate the business case, it becomes less appealing.

Turn to SaM Solutions if you need to assess Umbraco architecture, develop integrations, migrate to Umbraco from another CMS, or maintain your platforms. Our Umbraco development services connect CMS engineering with frontend delivery and customer experience requirements. Start with an assessment of your website portfolio to establish where consolidation will create practical value.

_{No time to read? Listen to the podcast:}

(Prefer videos? Watch a summary of this article below.)

Ask five enterprise software architects about Delphi, and you will likely get a nuanced answer. Unlike legacy platforms such as Visual FoxPro, the Embarcadero company continues to actively develop and support RAD Studio (IDE and umbrella software suite that contains Delphi as its primary programming language option). Because there is no artificial end-of-life cliff forcing an immediate shutdown, organizations running core Delphi applications rarely face an urgent vendor ultimatum.

The pressure appears organically: maintenance costs creep upward, experienced Object Pascal developers become increasingly scarce on the hiring market, legacy desktop architectures can’t normally integrate with modern cloud ecosystems, REST APIs, or AI-driven workflows. Many of these applications still run on aging data layers or deprecated reporting tools that haven’t seen active updates in decades.

When does legacy modernization become a strategic business decision? It happens when a legacy system begins constraining business growth. For organizations that already use Microsoft technologies, migrating from Delphi to .NET is often the most pragmatic path forward.

This guide examines what a Delphi to .NET migration involves, when the move makes sense, how to navigate the technical process, and how to protect critical business logic.

When Should You Migrate from Delphi to .NET?

You should think about migrating from Delphi to .NET when the existing application blocks business priorities and a .NET redesign offers benefits that justify the investment. The decision should be based on real constraints, e.g., rising maintenance effort or delayed releases.

Below are several situations that warrant a migration assessment.

• Routine changes have become disproportionately expensive. If to change a feature you need to edit across multiple forms, reports, and database procedures, tightly coupled code may be driving maintenance costs. Measure the effort spent on changes, then compare targeted refactoring with rebuilding the affected functionality in .NET.
• The business needs a different delivery model. For a company that needs browser access for customers, suppliers or distributed teams, the desktop application may no longer be a good match. Think about the workflows, the hosting model and the scalability requirements together. Moving to.NET gives an opportunity to redesign the application, but performance improvements still depend on implementation.
• Integration work conflicts with your technology strategy. If an organization already develops C# services, it may be complicated to maintain a separate Delphi application. A representative integration (e.g. synchronizing orders with an ERP system) may be enough to test the case for consolidation before committing to a complete rewrite.
• Unsupported components obstruct security improvements. A platform dependency that is obsolete or a library that is abandoned can block required patches or operating-system upgrades. Figure out which components are enforcing the restriction and whether supported replacements exist. 
• Essential knowledge is concentrated in too few people. If only one developer understands billing calculations or inventory allocation, staff turnover becomes an operational risk. Pair migration with business-rule documentation and knowledge transfer; changing programming languages alone will not remove that dependency.

“Why migrate from Delphi to .NET? Delphi built the basis of business operations decades ago (throughout the 1990s and early 2000s), but .NET is where modern enterprise software stays alive. Long-term stability is a major reason I’d choose .NET: Microsoft develops the platform and publishes clear support timelines. For a company already using Azure or SQL Server, it also fits the existing technology stack. Its mature libraries make API and cloud integration easier to implement. Then there’s staffing — a broader pool of .NET developers means more options for hiring and future development.”

— Dzmitry Verasau, Team Lead, Chief .NET Technologist at SaM Solutions

What Does Migrating from Delphi to .NET Involve?

Successful migration usually deals with four components: data architecture, business logic, user interface (UI), system integrations.

• Data architecture: Refactoring and migrating legacy data sources (Paradox, dBase, InterBase, older Microsoft Access databases or direct file access) to solid relational systems like Microsoft SQL Server or Azure SQL.
• Business logic: Experts take full advantage of modern object-oriented principles and modular architecture to rewrite the core computational rules, validation routines and domain workflows embedded throughout Delphi units and forms in C#.

• User interface (UI): Modern, responsive interfaces, ranging from desktop frameworks like WPF or WinForms to web-based architectures (ASP.NET Core, Blazor, or decoupled React/Next.js frontends) replace aging VCL (Visual Component Library) or FireMonkey (FMX) desktop forms. 
• System integrations: The re-architected modernized application natively integrates with modern enterprise ecosystems: identity providers (Azure AD/Entra ID), cloud storage, secure REST APIs, and AI-powered automation pipelines.

When Does a Delphi to .NET Migration Make Business Sense?

It is worth considering when the benefits (e.g, easier maintenance or better integration) obviously outweigh the cost and risk connected with the app rebuilding. Before deciding, you should compare the migration with a Delphi upgrade against the same business needs: planned features, security requirements, and how much longer the application is expected to stay in use. 

When staying with Delphi makes sense

• Stability and sufficiency: The application is stable, performs reliably, meets all current operational demands, and does not hinder business agility.
• Active in-house expertise: Your organization retains a reliable, experienced team of Delphi developers capable of maintaining, securing, and incrementally updating the codebase.
• Short-term horizon: The software supports a short-term project or a business unit slated to sunset within a few years, making a high-ROI migration economically unjustified.

When migrating to .NET becomes essential

• Architectural evolution: The business needs a transition from standalone desktop software to a multi-tier web application, cloud-native deployment, or distributed microservices.
• Talent acquisition constraints: Finding qualified Delphi and Object Pascal developers has become a persistent bottleneck, whereas .NET and C# talent is widely accessible.
• Ecosystem integration: The application must interact seamlessly with modern cloud services, web applications, or enterprise analytics platforms that reject direct desktop integration.
• Long-term maintainability and security: Compliance mandates, security audits, or ongoing technical debt make the legacy codebase increasingly expensive to secure and maintain.

Rely on SaM Solutions’ vast expertise in .NET development to deliver your .NET-powered product or custom software.

How Do You Plan a Delphi to .NET Migration?

Stakeholders and tech experts should assess the existing application, define the architecture, validate the project scope, agree on the business outcomes, acceptable downtime, and criteria for a successful release.

Assess the application and its dependencies

Legacy Delphi codebases may hide undocumented logic and rigid component coupling. For this, careful mapping should be done. Engineers audit .dfm forms, .pas units, and data layers to isolate critical dependencies, before C# refactoring begins. This way, they ensure zero lost business rules. 

Choose the target architecture and migration approach

Look at your actual working conditions and decide what you need: a desktop, web, or hybrid architecture. Browser access may suit distributed teams; offline operation or specialized hardware may favor retaining a desktop interface.

Next, decide whether to replace the application in one release or migrate individual functions gradually. For a phased approach, set clear boundaries between old and new functionality, define ownership of shared data, and plan for operating both systems during the transition.

Estimate scope, cost, and timeline

Estimate the effort by business workflow, accounting for complexity and dependencies. Include discovery, code conversion, refactoring, component replacement, testing, deployment, and user training. Budget for data migration where necessary and continued support for the Delphi application.

With a pilot project, you can check the assumptions, including how much manual work remains after automation. Present a budget and timeline range with explicit assumptions, delivery milestones, and contingency for unresolved dependencies.

How Do You Migrate a Delphi Application to .NET?

The process includes eight core steps: auditing, defining requirements, planning, reimplementing business logic and replacing unsupported components, migrating data and rebuilding integrations, rebuilding UI, testing, and deploying the final app with consequent post-launch support and training for users.

What Challenges Can Delay a Delphi to .NET Migration?

Delphi-to-.NET migrations stall primarily due to undocumented legacy code, obsolete dependencies, complex data transformations, and the adoption of end users. These problems inflate project timelines when left unaddressed. 

The “black box” problem

Undocumented business rules and updates accumulated over decades bury business logic deep within form event handlers and procedural Object Pascal scripts. This can cause unexpected discrepancies in the new system. Without formal specifications, developers risk missing vital edge cases during refactoring. Thorough discovery and close collaboration with domain experts eliminate this risk.

Unsupported third-party components

Many Delphi solutions use proprietary or abandoned third-party libraries that have no direct .NET equivalents. To avoid unexpected architectural bottlenecks, experts should rebuild such components from scratch, so they first should evaluate modern .NET components and UI libraries. 

Data compatibility and user adoption

To move messy, unstructured legacy data formats (like Paradox or dBase files) into a clean Microsoft SQL Server database, you need rigorous schema normalization and validation. Simultaneously, forcing dramatic interface shifts on employees who got used to legacy desktop workflows can slow down internal adoption. If you involve end users during the design phase, you can guarantee that the modernized application will enhance daily productivity and won’t disrupt daily operations. 

Which Delphi to .NET Migration Tools Can Help?

Ispirer Toolkit and VELO can assist with Delphi application conversion; SQL Server Migration Assistant handles supported database migrations.

Ispirer Toolkit

The Ispirer Toolkit is an automated migration platform for converting Object Pascal source code into C# and .NET environments. Ispirer Toolkit supports automated Delphi-to-C# conversion through its CodeWays application-conversion tool. Its capabilities cover business logic, supported interface elements, and database access code, with conversion rules that can be customized for individual projects.

VELO by GapVelocity

VELO is an agentic AI platform built by GAPVelocity AI (the AI modernization division of Growth Acceleration Partners) on Microsoft Foundry. You can use it to automate and modernize legacy enterprise applications into cloud-native C#/.NET and Blazor applications running on Microsoft Azure. VELO extracts business logic from Delphi VCL or FMX forms and transforms it into multi-tier .NET architectures.

SQL Server Migration Assistant

Microsoft’s SQL Server Migration Assistant (SSMA) is a specialized tool that addresses the database portion of modernization. It automates database migration from legacy engines like Access, Sybase, or MySQL (frequently paired with Delphi systems) to Microsoft SQL Server or Azure SQL. 

What Else Should You Know Before Starting?

Before migration begins, you should also discuss offline requirements, source-code ownership, access controls, downtime expectations, and handover documentation.

Why Choose SaM Solutions for Delphi to .NET Migration​?

To modernize a legacy Delphi application, you need a delicate balance of deep technical mastery and rigorous project governance. SaM Solutions offers such a balance! Our engineering teams combine decades of enterprise software modernization experience with advanced .NET and AI-driven development capabilities.

“At SaM Solutions, we have a tried-and-tested legacy migration process from Delphi to .NET based on the usage of local AI models. This means our clients reduce manual migration work and keep AI processing within a controlled environment.”

— Dzmitry Verasau, Team Lead, Chief .NET Technologist at SaM Solutions 

Here is a high-level description of our migration process.

Objective: Migrate a legacy software platform from Delphi to a modern .NET solution. Guarantee full functional parity and improve the overall quality of the codebase.

The tech stack: SaM Solutions’ team uses a local AI inference setup to secure and optimize operations. The core “intelligence” comes from the Qwen 3.8 Flash Next model, which is integrated into VS Code (the main environment/interface). Since we use local AI but not cloud-based services, we can guarantee data privacy and controlled infrastructure.

The structured process: 

1. Analysis and documentation: The local AI model reads and analyzes the original Delphi source code and generates a detailed functional description of how the application works.
2. Conversion: AI uses the functional descriptions as a blueprint and rewrites the application in .NET.
3. Human-in-the-loop verification: A human specialist monitors the entire process. The task is to verify the AI’s analysis and make sure that the newly written code adheres to the required functionality.
4. Database migration: The database is converted from InterBase to MS SQL in tandem with the application logic.
5. Quality assurance:
   • Automated test development
   • Analysis of test results
   • Subsequent bug-fixing

AI-Driven Legacy Code Modernization: How to Transform Outdated Systems with Artificial Intelligence

Summing Up

Rising maintenance costs or integration problems can turn a dependable Delphi application into a constraint on growth. Moving to .NET may address those pressures, but the investment needs to be weighed against a Delphi upgrade and the application’s remaining useful life.

_{No time to read? Listen to the podcast:}

(Prefer videos? Watch a summary of this article below.)

A huge number of enterprise software systems were developed about 20 years ago or more, which means they are built on monolithic architectures, legacy frameworks, or retired programming languages. According to Gartner, they may consume up to 70% of corporate IT budgets for maintenance alone. 

The era of artificial intelligence gives a perfect wayout for many companies suffering from legacy software limitations — legacy code modernization using AI​. Generative artificial intelligence and large language models (LLMs) are some of the technologies that can do a lot, for example automate code analysis, or reverse-engineer undocumented business logic, or refactor monolithic applications into modern architectures. 

McKinsey estimates that organizations deploying AI for legacy code modernization can cut migration timelines by up to 40-50% and at the same time reduce manual code translation errors. Read on to learn more on the topic.

What Is Legacy System Modernization and Why Does It Matter?

Legacy system modernization means moving an existing application from outdated technologies to a modern tech stack while preserving its functions, business rules, and workflows. The purpose is to keep software that already serves the business easier to maintain. It does not mean changing what the application does, but rather upgrading how and where it runs behind the scenes to guarantee long-term stability and maintainability. 

A system becomes “legacy” when its underlying technology creates problems: vendors may stop releasing security updates, compatible tools may become harder to find, and fewer developers may have the skills to maintain the code. Age alone is not the issue: a decades-old application can execute daily tasks reliably, but reliance on obsolete runtimes, unmaintained frameworks, or a shrinking pool of specialized developers (for COBOL, Delphi, or early Java and .NET Framework versions) makes keeping it on its original stack unsustainable.  

If you delay software modernization, you miss lots of opportunities current technologies offer to your business. In other words, you lag behind the competition.

Imagine a logistics firm that uses a 20-year-old Delphi application to calculate complex routing algorithms. Business math works and stands the test of time. But the desktop stack simply can’t scale to meet peak server load or connect to reporting tools. The modernization of this system is taking that exact same calculation engine and putting it into a modern .NET WPF application.

How Can You Identify When a Legacy System Needs Modernization?

Among the obvious indicators that you should modernize your legacy software are: operational maintenance costs surge (or it’s becoming harder to find experts), system modifications stall business releases, software versions reach end-of-life (EOL), there are no security updates, manual workarounds take too much time, software performance prevents from business development.

It’s better to prioritize modernization based on business impact and urgency. A slow internal report and an unreliable checkout process may both need attention, but their consequences are very different. Document the workflow affected, the cost or risk of leaving it as is, and the result the upgrade needs to achieve. These insights give you a clear starting point for your modernization roadmap.

Why Is AI Changing the Approach to Legacy Code Transformation?

Artificial intelligence makes legacy code modernization easier because it changes the traditional approach of rewriting old software manually line by line (a slow process) to automating many tasks and processes.

AI changes the game, as it combines high-speed automation with expert human control.

AI-assisted legacy code modernization is a human-guided workflow:

• Automating the routine: Generative AI reads through massive codebases, maps dependencies, uncovers undocumented business rules, and drafts initial translations from legacy stacks into modern frameworks.
• Keeping humans in control: AI handles the tedious work, but software architects stay firmly in the driver’s seat. Developers review every code draft and make final architectural decisions.

This human-in-the-loop approach eliminates manual busywork, but it doesn’t hand key technical decisions over to an algorithm. The upside is faster prep time, but AI-generated output still needs human review. Engineers decide which tasks to automate, assess the suggested changes, and compare the modernized application’s behavior with the original system. 

What Challenges Can AI Solve During Legacy System Modernization?

Artificial intelligence tools can translate existing features into documentation and back into code, adapt code to unsupported interfaces and changed APIs, and rebuild components that cannot be upgraded.

How Can AI Assist Developers in Modernizing Legacy Applications?

We’ve already mentioned that AI is an intelligent assistant throughout the modernization lifecycle, not a replacement of software engineers. Intelligent tools analyze code and create documentation, help with refactoring, code transformation, reverse engineering, and knowledge extraction, as well as conduct automated verification via MCP.

“Totally agree with the described approach. Modern LLMs are very useful in the modernization process. A modernisation task has clear verification steps, which makes reviewing the final solution simpler and many of those steps automatable.”

— Dzmitry Verasau, Team Lead, Chief .NET Technologist at SaM Solutions

How Should Companies Choose AI Models and Tools for Modernization Projects?

If you want to modernize your legacy software with the help of artificial intelligence, you should choose the right AI models and tooling. To do this in the best possible way, evaluate AI capabilities for different tasks, look at general-purpose and specialized models, take into account data privacy and security requirements, and examine integration flexibility.

What Is the Role of Developers and Architects in AI-Driven Modernization?

The process of AI-driven legacy code modernization switches developers and architects’ tasks from writing every line of code to guiding and checking the modernization. They turn from manual code writers to strategic system designers, code reviewers, and AI workflow supervisors.

• AI handles repetitive tasks: converting syntax, checking for mistakes, creating tests, etc.
• Engineers make bigger decisions: setting goals, designing the system, reviewing AI-generated code.

How Can Organizations Ensure Quality and Security During AI-Assisted Modernization?

They should enforce automated testing, continuous security analysis, strict compliance auditing, and multi-tier human governance.

Automated testing and validation

Automated regression testing guarantees that modern refactored applications reproduce exact business outcomes legacy platforms generate.

Developers implement “characterization testing” strategies, where AI tools observe legacy system inputs and outputs to create comprehensive regression test suites. Running these automated suites in parallel against both legacy and modern applications confirms functional parity.

Security analysis and compliance checks

AI-generated code must undergo automated Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), and open-source license audits.

Integrating tools such as SonarQube, Snyk, or Checkmarx into automated migration pipelines ensures newly refactored code adheres to OWASP Top 10 security standards. 

Human review and governance processes

Formal governance frameworks mandate multi-stage peer reviews and architectural approvals for all AI-transformed code modules.

Software teams implement strict pull request guidelines requiring at least two human software engineer approvals for AI-generated code. Peer reviews verify logic accuracy, readability, maintainability, and alignment with modern corporate coding standards.

What Are the Business Benefits of AI-Powered Legacy Transformation?

You can get compelling business advantages, including reduced costs, accelerated feature delivery, and mitigated operational risk.

Reducing modernization costs and development time

AI analyzes old code, drafts updates, and prepares tests, which means less manual effort. When the time saved exceeds the effort needed for review and corrections, businesses can finish upgrades sooner and free up engineering capacity for other priorities.

Increasing business agility and innovation speed

After modernization, software itself becomes easier to change. And artificial intelligence can reduce the work needed to understand and update individual components even further. For example, a team adding a payment option to an ecommerce app can use AI to explain existing checkout logic and draft changes, thus bringing the feature to market faster.

Reducing operational risks and improving security

AI explains flagged issues, suggests fixes, drafts tests, checks for compliance, and more. All these contribute to the software security and reduce different types of risks.

How Does the AI-Driven Modernization Process Work?

The AI-augmented legacy code modernization process follows five stages: assessing existing systems, planning the architecture, applying AI to selected tasks, migrating applications, and monitoring results. Importantly, engineers guide this process and decide when the app is ready for production.

What Are the Limitations of Using AI for Legacy Modernization?

Companies must account for some major hardships of using artificial intelligence for software modernization: hallucinations, architectural blind spots, data privacy risks, and human oversight.

Hallucinations and silent logic drift in edge cases

The challenge: AI tools produce code that looks clean, compiles without errors, and passes basic checks. However, it can sometimes quietly change core business logic or misinterpret subtle edge cases.

Why it happens: Legacy enterprise code contains years of obscure bug fixes and implicit workarounds. To an LLM trained, among other things, on modern open-source repositories, these routines can look redundant or inefficient. The AI may “clean them up” and unintentionally remove functionality the business still depends on.

Mitigation: Never treat AI outputs as production-ready. Validate every AI-translated module against automated characterization tests created from the original running legacy system before human architects give final approval.

Architectural blind spots across massive monoliths

The challenge: AI models are strong at local, file-by-file refactoring, but they can’t maintain a full understanding of architecture across monolithic codebases with millions of lines.

Why it happens: Even with larger context windows, LLMs process code in smaller batches. As a result, they can miss implicit global state, side effects between modules, hidden database triggers, and circular dependencies spread across hundreds of legacy directories.

Mitigation: You should have human software architects who will define the overall architecture, microservice boundaries, and domain models first. Then use AI for focused, lower-level work (e.g., translating code and refactoring individual components) within those boundaries.

Data privacy risks and security concerns

The challenge: It’s a common situation that enterprise source code, system configurations, or database schemas contain proprietary business logic, credentials, or sensitive customer data. If you send this unreviewed code to commercial AI services, you can involuntarily expose trade secrets or breach regulatory requirements, especially in industries like finance and healthcare.

Why it happens: Big players like Microsoft, Anthropic, and OpenAI have different terms depending on the service and agreement. Then there are aggregators, where it’s often unclear how they actually handle your data.

Mitigation: Use zero-data-retention (ZDR) enterprise agreements, remove credentials and sensitive information from code before submitting it to AI tools, or run self-hosted open-source models in isolated private cloud environments (Virtual Private Clouds or VPCs).

Maintaining human oversight throughout the transformation process

The challenge: Let’s be honest, fully autonomous, end-to-end modernization without human involvement is not realistic. If you treat AI as an unsupervised developer, you risk releasing unverified changes that may not support core business goals or meet production security standards.

Why it happens: AI tools can produce plausible code changes, but they cannot take responsibility for system safety or business intent. Validating, testing, and correcting probabilistic AI output also requires significant engineering effort — something teams often underestimate during project planning.

Mitigation: Put a formal human-in-the-loop governance model in place, with clear review responsibilities for architects, developers, and product owners. AI can suggest changes, but people must decide whether those changes support the business and are safe to release. Their time should be included in the project plan, since checking and correcting AI output can be substantial work.

What Does the Future of AI-Assisted System Transformation Look Like?

In the near future AI-assisted system transformation will be a partnership between people and AI. AI agents will increasingly analyze old code, suggest modernization plans, generate and test code.

Developers and architects will still make the key decisions. They will set the goals, review important changes, protect security and data, and handle complex business rules. The most successful approach is likely to use AI for repetitive work and people to provide judgment, oversight, and accountability.

Why Choose SaM Solutions for AI Legacy Code Modernization​?

SaM Solutions is a long-standing player in the IT market. We combine more than 30 years of software engineering experience with expertise in AI development and legacy modernization.

So you get one partner who can offer:

• Practical experience with modern and outdated technologies
• Human engineering and automated AI capabilities
• Cloud, QA, API, and DevOps services

Summing Up

Legacy modernization no longer has to be a multi-year gamble. If you combine intelligent AI tools with experienced software architects, you can reduce technical debt and preserve decades of essential business logic. Waiting only increases maintenance costs and security risks. Modernizing now gives your team the freedom to build something new and innovative. 

_{No time to read? Listen to the podcast:}

(Prefer videos? Watch a brief summary of this article below.)

AI coding tools can accelerate software delivery, but speed alone does not guarantee that generated code reflects business requirements, architectural constraints, or product intent.

This guide explains how the BMAD Method supports spec-driven development, which artifacts and workflow phases it uses, how agent orchestration maintains context and quality, and when the approach makes sense for enterprise and product teams.

What Is Spec-Driven Development with the BMAD Method?

BMAD is an acronym for “Build More Architect Dreams.” Spec-driven development with BMAD is an AI-assisted approach in which structured requirements guide implementation. The main goal is not to leave an AI coding agent to infer the product from a series of prompts. To turn business intent into controlled software delivery, BMAD combines:

• Specifications
• Specialized agents
• Defined workflows
• Human checkpoints

Definition and core principles

The BMAD Method treats documented intent as the foundation for AI-native development. Depending on project complexity, you can define capabilities, success conditions, constraints, non-goals, architecture decisions, and acceptance criteria.

This reduces the number of assumptions an AI agent must make. A vague instruction such as “add secure authentication” still leaves decisions about login methods, sessions, recovery flows, and access rules unresolved. BMAD moves those decisions into explicit requirements, where experts can review them before code is generated.

BMAD is also proportional: a small, well-defined change may require only a lightweight specification, while larger initiatives may need a PRD, UX documentation, architecture, and story breakdown. 

From informal prompts to structured requirements

BMAD turns informal requests into implementation-ready requirements. A developer may start with a sentence, issue, or rough feature idea, but ambiguous work is clarified before the AI proceeds.

For example, “Add subscription cancellation to the customer portal” raises immediate questions: 

• When does cancellation take effect?
• What happens to prepaid access? 
• Can users reactivate later? 

A structured specification makes those decisions explicit instead of allowing the coding agent to invent them.

The role of context engineering

Context engineering is central to BMAD because AI output depends on the information available to the model. BMAD organizes requirements, architecture rules, repository conventions, and implementation constraints into focused context for each task.

The goal is not to give the AI every project document. It is to provide the smallest coherent set of information required for the current decision. 

How Does the BMAD Method Work?

BMAD progressively refines intent, assigns tasks to AI agents, and involves humans where judgment is most important. The workflow can expand for complex projects or remain lightweight for smaller changes.

Progressive context creation

BMAD creates context in layers. Broad product goals can become requirements, architecture decisions, specifications, and finally implementation stories.

Each layer answers a narrower set of questions. A product requirements document (PRD) defines what the product should achieve, architecture establishes shared technical decisions, and a specification describes what a particular feature must do. Smaller tasks can skip unnecessary stages and move directly to implementation.

Specialized AI agents

BMAD doesn’t rely on one general-purpose assistant for every development activity; it divides work among specialized AI roles. These roles typically cover analysis, product management, architecture, UX design, development, testing, and review.

Specialization creates clearer responsibility boundaries. Product decisions are less likely to be reinterpreted during coding, while architecture and acceptance criteria remain visible throughout implementation.

Structured workflows and human oversight

AI-generated decisions are not treated as automatically correct, so BMAD combines automation with human oversight. Humans remain involved in defining intent, resolving ambiguity, approving high-impact plans, and evaluating final results.

What Are the Four Phases of the BMAD Workflow?

The BMAD workflow structures AI-assisted software development into four phases: Analysis, Planning, Solutioning, and Implementation. But for small, well-understood changes, BMAD also supports a Quick Flow that can bypass the first three phases and move directly into a streamlined development cycle.

Which Artifacts Does the BMAD Method Produce?

The BMAD Method produces a set of structured artifacts that carry business intent from discovery into implementation. The exact set depends on project complexity: smaller initiatives may rely mainly on SPEC.md, while larger projects can add a product brief, PRD, UX documentation, architecture, epics, stories, and sprint tracking. 

How Can You Implement Spec-Driven Development with the BMAD Method Step by Step?

Implementing BMAD spec-driven development means moving from an initial idea to a validated specification, architecture, delivery plan, and controlled implementation. The process can be shortened for small tasks or expanded for enterprise projects.

How Do BMAD Agents Maintain Context and Software Quality?

BMAD maintains context and software quality through specialized agents, shared project artifacts, validation gates, and structured review cycles.

What Are the Benefits and Limitations of the BMAD Approach?

The BMAD Method improves control over AI-assisted development by making requirements, context, and review criteria explicit. Its main trade-off is additional process: the more structure a team introduces, the more effort it must invest in maintaining useful documentation and workflows.

Greater requirement clarity

BMAD turns vague ideas into explicit requirements, constraints, and success criteria. This gives product, engineering, and AI agents a shared understanding of what should be built.

More predictable AI outputs

Structured specifications reduce the number of decisions an AI agent must infer independently. As a result, generated code is more likely to stay aligned with product intent and technical constraints.

Reduced rework

Early validation helps teams identify missing requirements and conflicting assumptions before implementation. Fixing these issues during planning is generally easier than correcting them after they have spread across code, tests, and integrations.

Documentation overhead

BMAD can introduce significant documentation effort on larger projects. Teams need to create and maintain artifacts such as PRDs, specifications, architecture documents, and stories, which may be unnecessary for simple changes.

Initial learning curve

BMAD requires teams to understand its agents, workflows, artifacts, and planning paths before they can use the framework efficiently. Early adoption may therefore involve more process than familiar prompt-based coding.

Risk of excessive planning

Overusing BMAD artifacts can turn useful structures into bureaucracy. Teams should match planning depth to project complexity and avoid creating documents that do not materially improve implementation decisions.

How Does BMAD Compare with Other Software Delivery Approaches?

BMAD differs from vibe coding, traditional agile, and ad hoc AI coding mainly in how it manages requirements and context. Its defining feature is a structured chain from intent and specifications to implementation and review, while still allowing small changes to bypass unnecessary planning. 

BMAD versus vibe coding

BMAD prioritizes explicit intent and review, while vibe coding prioritizes speed and experimentation. Vibe coding, a term introduced by Andrej Karpathy in 2025, describes a highly conversational style in which developers let an LLM generate changes without necessarily examining or understanding every implementation detail.

That flexibility can be useful for prototypes and low-risk experiments. BMAD is better suited to work where requirements, maintainability, architectural consistency, and traceability matter because AI operates within defined specifications and project context rather than relying primarily on iterative prompting.

BMAD versus traditional agile

BMAD and agile address different layers of software delivery and can complement each other. Traditional agile emphasizes customer collaboration, frequent delivery, adaptability, and working software, rather than prescribing how AI agents should receive and preserve development context.

BMAD adds an AI-oriented execution layer through specifications, architecture artifacts, agent workflows, implementation readiness checks, and structured reviews. An agile team can therefore use BMAD inside its existing delivery model rather than replacing sprints, stakeholder collaboration, or iterative planning.

BMAD versus ad hoc AI coding workflows

BMAD replaces isolated prompt-and-response coding with reusable context and repeatable workflows. In an ad hoc AI workflow, developers may describe a task, review the generated code, add corrections, and repeat the process without maintaining a formal connection between business requirements, architecture decisions, and implementation.

BMAD preserves those connections through artifacts such as SPEC.md, project context, architecture documentation, and stories. This requires more preparation, but it gives larger teams a clearer basis for reviewing whether AI-generated software matches the original requirements rather than simply whether the code appears to work.

When Should Teams Use the BMAD Method?

BMAD is most valuable when software work involves ambiguity, architectural complexity, high risk, or coordination across people and teams. The framework can also support small changes, but BMAD recommends matching planning depth to the scope instead of applying the full workflow to every task. 

Complex greenfield products

BMAD is well suited to new products with uncertain requirements and significant technical scope. Product discovery, PRDs, architecture, and specifications help teams resolve key decisions before AI agents begin implementation.

Enterprise applications

Enterprise projects benefit from BMAD when they require stronger governance, traceability, architectural consistency, or extensive testing. BMAD also provides an enterprise-oriented testing path for complex or regulated environments.

Multi-team projects

BMAD helps multiple teams work from shared requirements and architectural decisions. Common artifacts reduce the risk that separate developers or AI agents interpret the same product goal differently.

High-risk features

Features with security, compliance, cross-system, or high business impact justify deeper planning. BMAD explicitly recommends more preparation when work has high risk, unclear requirements, broad architectural reach, or cross-system effects.

Small fixes and simple prototypes

Small, clearly bounded tasks rarely require the full BMAD workflow. BMAD allows straightforward changes to enter implementation directly, while slightly larger tasks can use a lightweight specification before coding.

The practical rule is to scale BMAD planning with project risk and complexity. More structure is useful when mistakes are expensive; for low-risk work, the shortest safe path is usually the better choice.

What Are the Best Practices for Successful BMAD Adoption?

Successful BMAD adoption depends on disciplined requirements, proportional planning, and consistent review. Teams should use BMAD to reduce ambiguity and improve delivery control, not to create documentation for its own sake.

Summing Up

The BMAD Method brings more structure and control to AI-assisted software development as it connects requirements, architecture, implementation, and review through shared artifacts and defined workflows. Its main value is reducing the amount of critical product and technical judgment left to ad hoc prompting.

BMAD is especially relevant for complex, high-risk, and multi-team projects where traceability and consistency matter.

_{No time to read? Listen to the podcast:}

(Prefer videos? Watch a brief summary of this article below.)

Claude Code can accelerate software delivery, but conversational prompts alone leave critical requirements open to interpretation. Spec-driven development addresses this problem by defining expected behavior, technical boundaries, and completion criteria before implementation begins. This guide explains how to prepare effective specifications, move from requirements to verified code, and scale the workflow across development teams.

What Is Spec-Driven Development with Claude Code?

Spec-driven development (SDD) with Claude Code is a structured workflow in which teams define what software must do before an AI agent begins implementation. The specification establishes requirements, constraints, architecture, acceptance criteria, and exclusions, while Claude Code explores the repository, prepares an implementation plan, writes the code, and verifies the result against those documented expectations. Unlike a conversational prompt, a specification remains available throughout the development cycle. 

What Is Spec-Driven Development? A Complete Guide

Specification as the source of truth

The specification becomes the source of truth when every design decision, code change, and test can be traced to an explicit requirement. 

Consider a requirement to add rate limiting to a customer-facing API. “Add rate limiting” leaves Claude Code to choose the algorithm, scope, thresholds, storage mechanism, and error response. A stronger specification states that authenticated users may make 100 requests per minute, counters must be shared across application instances, exceeded limits must return HTTP 429 with a Retry-After header, and internal health-check endpoints are excluded. Claude Code can then convert each requirement into implementation tasks and tests instead of filling critical gaps with reasonable but unapproved assumptions.

The role of human review

In spec-driven development, human review is moved upstream from after-the-fact code review to explicit gatekeeping during design, planning, and pre-merge stages. When AI agents like Claude Code can generate hundreds of lines of code in seconds, traditional pull request reviews become serious operational bottlenecks and manual line-by-line inspection becomes impossible.

SDD restructures verification into three distinct human review gates:

DORA’s research on AI software delivery shows that companies that impose structured verification gates realize high throughput gains without the delivery instability that is associated with unstructured AI adoption. 

Hence, senior developers should not look for syntax bugs in large diffs but should validate architectural specs before code execution starts.

Why Does Vibe Coding Fail on Complex Projects?

Vibe coding (the practice of feeding conversational prompts to AI agents instead of written design constraints) fails on enterprise applications because large language models must guess unstated technical requirements. The AI coding agent must infer missing requirements, and those individually plausible assumptions can accumulate into a system that works in isolated demonstrations but fails to satisfy the original business objective. 

How Does Spec Driven Development Differ from Plan Mode?

Claude Code’s plan mode controls when implementation begins, whereas spec-driven development governs the entire journey from requirements to verified software. Plan mode lets Claude Code examine a repository and propose changes without editing files until the user approves the plan; spec-driven development adds persistent requirements, review gates, traceability, and validation against an agreed source of truth.

How Do You Prepare an Effective Specification?

An effective specification implies that you give Claude Code enough information to implement the correct solution without inventing product decisions or violating technical boundaries.  

Business goals and user scenarios

Business goals explain why the feature deserves to exist. User scenarios show who needs it and how it will be used. 

Instead of asking Claude Code to “build a customer data export,” specify that the feature should reduce manual support requests and allow account owners to retrieve their data without staff assistance. 

A representative scenario might state: “An authenticated account owner requests an export from the privacy settings page, receives a notification when it is ready, and downloads it within 24 hours.” 

Functional requirements

Functional requirements define the observable behavior the software must provide. For the data-export feature, the specification should identify:

• Authorized roles
• Included records
• Supported formats
• Request limits
• Job statuses
• Notification behavior
• Download expiry
• Audit events

Each requirement should use language that can be tested: “The system must reject a second export request while another request is processing” is more useful than “The system should prevent unnecessary exports.” 

Technical constraints

Technical constraints tell Claude Code which solution space is acceptable. A specification may require the export process to use the existing worker queue, store encrypted files in the approved object-storage service, preserve current public API contracts, and avoid introducing another third-party dependency.

Edge cases and acceptance criteria

• Edge cases describe conditions outside the ideal workflow. 
• Acceptance criteria convert the specification into a pass-or-fail contract. 

The data-export specification should cover large accounts, duplicate requests, deleted records, revoked permissions, interrupted jobs, unavailable storage, and expired download links. Acceptance criteria can then state measurable outcomes, for example, a user whose access is revoked before completion must not receive a valid download link, and a failed job must produce an audit event without exposing partial data. 

How Does CLAUDE.md Support Spec-Driven Development?

CLAUDE.md is the persistent memory and steering layer for Claude Code. It automatically loads repository-specific instructions into context at the start of every terminal session. CLAUDE.md establishes project conventions, repository structures and verification commands in version control to prevent context drift and steer AI agent execution in accordance with enterprise engineering standards. 

Project instructions and conventions

CLAUDE.md applies coding standards, naming rules, and hard negative constraints at the project level, directly in Claude Code terminal sessions. Without guidance, natural language LLMs tend to fall back to generic code patterns, but enterprise repositories require strict adherence to governance policies.

Repository architecture

Claude Code instantly maps target modules, interfaces, and test directories saving context tokens on exploratory file searches due to indexing repository layout within CLAUDE.md. In large multi-package monorepos or legacy microservices, unguided AI agents waste context window capacity scanning directories that don’t need scanning. 

Build and testing commands

With defined explicit build, linting, and test execution scripts in CLAUDE.md, Claude Code runs automated verification loops and self-correct failing builds before requesting human code review. Spec-driven development requires deterministic proof of working software rather than relying on unverified model assertions. 

Instruction scope and maintenance

If you keep CLAUDE.md concise (ideally under 200 lines) and delegate deep feature instructions to lazy-loaded .claude/rules/ files, it prevents context window degradation and maintains strict instruction adherence. During the expansion of enterprise software projects, bloated instruction files dilute model attention, causing Claude Code to skip advisory rules during long coding sessions. 

How Does the Workflow Move from Specification to Implementation?

The workflow moves through six controlled stages: repository exploration, requirement clarification, specification writing, technical planning, implementation with testing, and final diff review.

How Can Tests, Hooks, and Agents Enforce the Specification?

Tests, hooks, and specialized agents turn a written specification into repeatable checks throughout development. Tests verify expected behavior, hooks provide the automation of selected controls, and agents divide implementation and review into focused responsibilities.

• Requirements-to-test mapping. Each test should reference a specific requirement or acceptance criterion, creating a visible link between the specification and executable evidence. This mapping helps reviewers detect unimplemented requirements and not only rely on broad coverage percentages.
• Automated validation. Hooks can automatically run tests, linters, type checks, security scanners, or policy scripts before Claude Code completes an action or finishes a task. Unlike instructions in CLAUDE.md, which guide model behavior, hooks execute deterministic controls and can block progress when a required check fails. 
• Task decomposition. Agents can divide an approved plan into bounded tasks with explicit inputs, outputs, dependencies, and acceptance criteria. One agent might implement a database migration while another prepares API contract tests in an isolated worktree. Decomposition reduces context pressure and makes each result easier to compare with the relevant part of the specification, although shared interfaces should be agreed before parallel work begins.
• Independent verification. A separate agent should review the final diff against the specification without inheriting the implementer’s reasoning. The reviewer can identify missing requirements, untested edge cases, architectural violations, and unrelated changes, then return concrete findings for correction. Human approval should remain the final gate for material business, security, and release decisions.

Which Frameworks Can Extend Claude Code?

Open-source frameworks like Superpowers, GitHub Spec Kit, and BMAD Method add specialized capabilities to Claude Code. 

Superpowers

Superpowers is a plugin-based skills framework that automatically hooks into Claude Code at session start to enforce software development discipline. Rather than executing ad-hoc prompts, Superpowers guides the agent through explicit skill phases, e.g., mandatory architectural brainstorming, git worktree isolation, and Test-Driven Development (TDD) loops. It dispatches dedicated subagents to run a two-stage code review (spec compliance followed by code quality) for every task before merging changes, ensuring unverified code never hits the main branch.

GitHub Spec Kit

GitHub Spec Kit provides an artifact-driven workflow built around a project constitution, feature specification, technical plan, task list, implementation, and convergence review. Its commands deliberately separate what and why to build from technology and architecture decisions, creating a traceable path from requirements to code.

BMAD Method

BMAD Method applies an adaptive, role-oriented process to AI-assisted development. The framework preserves product and technical decisions as durable context and can introduce specialized product, architecture, UX, development, and testing perspectives when project complexity requires them. Smaller changes can move directly toward implementation, while larger initiatives receive deeper discovery and planning. 

Choosing the right framework

Selecting the appropriate framework depends on team size, process rigor, and the level of autonomy required for your development workflow.

• Use Superpowers if you want seamless, terminal-native TDD and automated subagent code reviews without altering your repository structure.
• Use GitHub Spec Kit if you require strict, standardized Markdown templates (spec.md, plan.md) and command-line gates across cross-functional engineering teams.
• Use BMAD Method if you are managing complex, multi-epic features that require architectural modeling, dedicated QA roles, and extended autonomous execution.

What Are the Benefits and Limitations of Claude Code Spec-Driven Development?

Spec-driven development makes Claude Code more predictable, as it replaces implicit expectations with persistent requirements, review gates, and verification criteria. The trade-off is additional planning and maintenance: specifications can become outdated, long sessions can exhaust useful context, and excessive process can slow down simple changes.

How Can Teams Adopt and Scale the Workflow?

Teams should introduce Claude Code spec-driven development through a controlled pilot, then scale the practices that produce better delivery outcomes. Shared templates, clear ownership, quality metrics, and mandatory synchronization between specifications and code turn an individual technique into a repeatable organizational workflow. 

• Start with a pilot project: Choose one representative project with meaningful complexity, measurable outcomes, and manageable delivery risk. A multi-file feature with clear users and acceptance criteria is more informative than a trivial bug fix or business-critical migration. 
• Create shared templates: They give you a consistent starting point for specifications, technical plans, task lists, and review checklists. A specification template should cover business goals, user scenarios, functional requirements, constraints, edge cases, exclusions, and acceptance criteria without forcing every project into the same level of detail. 
• Establish governance: Governance should define who authors, approves, changes, and verifies each specification. Product owners may approve business behavior, architects may own system boundaries, security specialists may review sensitive workflows, and engineering leads may authorize implementation.
• Measure delivery quality: Compare pilot results with similar work completed under the existing process. The workflow should scale only when it improves outcomes without adding disproportionate planning and review effort. 
• Keep specifications and implementations aligned: Specification updates should accompany implementation changes in the same pull request whenever product behavior, architecture, or acceptance criteria evolve. Reviewers should compare the final diff, tests, and documentation with the approved specification before release. 

Summing Up

Spec-driven development using Claude Code turns informal requests into a controlled workflow built around explicit requirements, technical plans, testing, and review. It helps teams reduce ambiguity, limit architectural drift, and evaluate generated code against measurable acceptance criteria. The approach delivers the greatest value on complex or high-risk projects where predictability and traceability justify the additional planning effort.

_{No time to read? Listen to the podcast:}

(Prefer videos? Watch a brief summary of this article below.)

The cost of training large language models from scratch in 2026 can be anywhere from tens of thousands of dollars for a narrowly scoped small model to well over $100 million for a large-scale system. 

For reference, public estimates place GPT-4 training compute at approximately $78–100 million and Gemini Ultra 1.0 at about $191–192 million, compared with $670–900 for the original Transformer in 2017. 

These figures are not directly comparable because AI companies rarely disclose complete budgets, but they show how sharply the economics of LLM development have changed.

How Much Does It Cost to Train an LLM From Scratch in 2026?

Based on open sources, the cost of training an LLM from scratch currently ranges from $50,000 to $500,000 for a small model, $1 million to $6 million for a 70-billion-parameter-class model, and more than $200 million for large-scale training.

Typical 2026 budget ranges

Publicly documented models illustrate just how much the economics can differ.

The table shows why parameter count alone cannot determine an LLM training budget. DeepSeek-V3 reportedly contained 671 billion total parameters but had a published compute estimate of approximately $5.6 million, while GPT-4 and Gemini Ultra estimates reached tens or hundreds of millions of dollars. 

What counts as training an LLM from scratch?

Training an LLM from scratch means creating the model’s base capabilities by initializing new model weights and pre-training them on a large corpus. Remember, it is not starting with an already trained foundation model. 

The project normally includes:

• Defining or selecting the architecture
• Building the tokenizer and training dataset
• Filtering and deduplicating data
• Running distributed pre-training
• Validating checkpoints
• Evaluating the resulting base model 
• Post-training/fine-tuning the model

Why published cost estimates vary so widely

A figure described as a “$50 million training cost,” for example, may represent only the accelerator time consumed by the final successful run, while another estimate may include experimental runs, data preparation, engineers, infrastructure, energy, and hardware depreciation.

How to Calculate LLM Training Costs

You need to estimate the compute required for the model, convert that compute into GPU-hours, apply the effective price per GPU-hour, and then add data, engineering, infrastructure, experimentation, and contingency costs.

The core LLM training cost formula

The simplest LLM training cost formula is GPU-hours multiplied by the effective cost per GPU-hour. A fuller project calculation looks like this:

For cloud infrastructure, compute can be estimated as:

For example, a cluster of 512 GPUs running continuously for 30 days consumes 368,640 GPU-hours. At an effective rate of $2 per GPU-hour, the final run alone would cost about $737,000, before data preparation, salaries, experiments, storage, or post-training are included.

When the required training compute is known in FLOPs (Floating point operations per second) rather than hours, the formula becomes:

GPU hours, cluster size, and utilization

• GPU hours equal the number of GPUs reserved multiplied by the hours for which the training job runs. 
• Cluster size changes calendar time more directly than it changes total compute spend. Doubling the number of GPUs can shorten a well-parallelized run, but it may not halve the bill if network communication, memory limits, failures, or data-loading bottlenecks reduce scaling efficiency.
• Model FLOPs utilization (MFU) measures how much of a GPU’s theoretical processing capacity is converted into useful model-training work. For example, improving MFU from 30% to 60% can halve training time for the same workload, which can have an effect comparable to doubling the GPU fleet.

Parameters, tokens, and training FLOPs

For a dense transformer, training compute can be approximated from two core variables: the number of model parameters and the number of training tokens. A widely used heuristic is:

Failed runs, experiments, and budget contingency

The final training run is only part of the cost. GPU spend also covers experiments, data trials, debugging, evaluation, and post-training.

Set aside contingency based on project risk. Proven architectures need less reserve than new models, proprietary datasets, or unfamiliar language requirements.

What Are the Main Expenses Involved in LLM Training?

LLM training costs include compute, data, specialist labor, infrastructure, energy, and model assurance. A reliable budget must include all six categories, not only the GPU bill.

• Compute hardware and accelerator rental: GPU or accelerator costs for pre-training, fine-tuning, experiments, and retries. The total depends on GPU hours, cluster size, hourly rates, and hardware utilization.
• Data collection, licensing, cleaning, and tokenization: Costs of acquiring permitted data and turning it into a usable training corpus. This includes licensing, deduplication, privacy filtering, quality checks, formatting, and tokenization.
• Engineering, research, and MLOps talent: Salaries or service fees for ML engineers, data engineers, researchers, MLOps specialists, security professionals, and QA teams.
• Networking, storage, checkpointing, and data transfer: Infrastructure costs for storing raw and processed datasets, model checkpoints, experiment logs, and model versions. 
• Electricity, cooling, and carbon accounting: Direct operating expenses for companies running their own AI infrastructure, plus energy and sustainability reporting costs. Data-center electricity demand increased by 17% in 2025, driven in part by AI workloads.
• Evaluation, red teaming, safety, and alignment: Costs of testing model accuracy, security, bias, privacy, harmful outputs, and resistance to adversarial prompts. Red teaming identifies safety and misuse risks before the model enters production.

What Are Realistic LLM Training Budgets by Model Scale in 2026?

The reality in 2026 is that large language model training costs​ vary from $50,000 for a compact domain model to tens or hundreds of millions of dollars for frontier-scale systems. The required investment depends not only on parameter count, but also on training-token volume, architecture, accelerator choice, experimentation, data preparation, and infrastructure efficiency. 

How Has DeepSeek Changed the Economics of LLM Training?

DeepSeek demonstrated that a frontier-capable LLM can be trained with substantially less final-run compute than earlier public estimates suggested, but it did not make frontier-model development a $5.6 million undertaking. Its results shifted attention toward architecture efficiency, low-precision training, GPU utilization, and transparent cost accounting.

What the reported DeepSeek-V3 figure actually covers

DeepSeek-V3 combined a sparse Mixture-of-Experts architecture with low-precision training and extensive system-level optimization. It showed that architecture and infrastructure efficiency can matter as much as total parameter count.

DeepSeek reported that DeepSeek-V3 used 2.788 million H800 GPU hours: 2.664 million for pre-training, 119,000 for context-length extension, and 5,000 for post-training. At an assumed H800 rental rate of $2 per GPU hour, this equals approximately $5.576 million.

Why final-run compute is not the total development budget

The $5.576 million figure should not be interpreted as the full cost of creating DeepSeek-V3. DeepSeek explicitly states that the estimate covers only the official model training and excludes earlier research and ablation experiments involving architectures, algorithms, and data; it also does not represent the full cost of engineering talent, data preparation, infrastructure development, or the work behind earlier DeepSeek models. 

Which DeepSeek efficiency gains can other teams replicate?

Other teams can adopt several of DeepSeek’s cost disciplines: 

• Use mixed-precision training where hardware and model stability allow it 
• Improve cluster utilization with optimized distributed-training pipelines 
• Reduce data waste through strong curation and deduplication
• Benchmarks throughput before scaling GPU capacity

But not every organization can reproduce DeepSeek’s results. MoE routing, FP8 stability, custom communication kernels, and large-scale parallel-training optimization demand deep research expertise and specialized infrastructure.

Training from Scratch vs. Fine-Tuning vs. Open-Weight Adaptation

Training from scratch means initializing a new model and pre-training its weights on a large dataset, giving the organization maximum control over the architecture, training data, and resulting model behavior. Fine-tuning means taking an already trained foundation model and updating some or all of its weights with a smaller, task- or domain-specific dataset to improve performance for a particular use case. Open-weight adaptation means building on a model whose trained weights are available for modification or deployment, using techniques such as fine-tuning, LoRA, continued pre-training, or domain-specific alignment instead of paying for base-model pre-training.

LLM training approaches compared 

* Most AI labs prefer fine-tuning existing foundation models rather than training new ones from scratch, as it is significantly faster and more cost-efficient. Releases such as Ornith 1.0 and Ornith 1.5 illustrate this approach: they build on available base models and adapt them for improved instruction following, domain performance, or other targeted capabilities.

Full pretraining economics

Full pretraining demands the largest budget because the organization must fund general-language learning across billions of parameters and trillions of tokens. It is justified primarily when proprietary data, sovereignty requirements, or a long-term model strategy create value that existing models cannot provide.

Fine-tuning, LoRA, and continued pretraining

• Fine-tuning updates an existing model with labeled examples. 
• Continued pretraining adapts it to specialized unlabeled data using the original self-supervised objective. 
• LoRA is a parameter-efficient fine-tuning method that keeps the base model frozen and trains small low-rank adapter layers, reducing compute and storage requirements; if needed, the trained adapter weights can later be merged into the base model for simpler standalone deployment.

When an existing open-weight model is the better choice

It is usually the better option when speed, predictable cost, private deployment, and domain adaptation matter more than owning a new foundation model. The organization can run permitted weights in its cloud or on-premises environment, integrate proprietary CMS or ecommerce data through retrieval, and fine-tune only where evaluation shows a measurable gap.

Cloud vs. On-Premises LLM Training Costs

Cloud infrastructure is usually more cost-effective for occasional or unpredictable LLM training. On-premises GPU clusters can reduce the cost per useful GPU-hour when workloads remain consistently high for several years. The right choice depends on utilization, access to capital, required capacity, security constraints, and whether the organization values flexibility more than long-term infrastructure ownership.

Cloud GPU pricing, discounts, and capacity risks

Cloud H100 rates vary by provider, region, and commitment, typically ranging from $2 to $10 per GPU hour in 2026. AWS Capacity Blocks and SageMaker training plans can cut prices by 40–75% with advance scheduling and upfront commitments.

Savings Plans lower costs but do not reserve GPUs; Capacity Blocks provide guaranteed capacity for a specified period. Deadline-sensitive LLM projects should secure capacity before committing to delivery dates.

On-premises hardware, depreciation, and utilization

On-premises LLM training requires upfront spending on GPU servers, networking, storage, power, cooling, support, and operations. Total cost of ownership also includes depreciation, electricity, maintenance, security, and idle capacity.

Owned infrastructure pays off only when GPUs stay heavily utilized for training or inference. Cloud resources avoid the cost of idle hardware because teams pay only while workloads run.

When on-premises infrastructure reaches break-even

It happens only when an organization can keep a GPU fleet heavily utilized for several years. One total-cost model identifies 60–70% utilization as the typical break-even zone, with on-premises infrastructure gaining a clearer economic advantage above 70% utilization.

What Are the Hidden Costs After LLM Pretraining?

Pretraining produces model weights, not a finished enterprise AI product. Ongoing costs arise from serving the model reliably, measuring quality, protecting data, meeting governance requirements, and responding to failures in production.

• Inference and model-serving infrastructure: Production LLMs need GPU or accelerator capacity, load balancing, autoscaling, API gateways, vector databases or retrieval services, caching, and token-cost controls. 
• Evaluation, updates, and retraining: Model performance can degrade as product catalogs, policies, user behavior, or domain terminology change. Teams may need recurring evaluation datasets, test automation, human review, and retraining or fine-tuning cycles triggered by new business requirements.
• Security, compliance, and AI governance: For enterprise deployments, access control, privacy protection, audit logs, data-retention policies, license management, model-risk assessment, and documented approval processes are a must. 
• Observability, maintenance, and incident response: LLM operations require monitoring of latency, errors, throughput, GPU utilization, token consumption, output quality, and unsafe behavior to detect model drift, infrastructure bottlenecks, hallucinations, and security events.

What Drives LLM Training Costs Higher?

LLM training costs rise with model complexity, data requirements, infrastructure inefficiency, and the amount of expert experimentation needed to reach a stable result. 

• Model architecture and active parameters: Larger or less efficient models require more compute.
• Data quality and token volume: More tokens and heavier data preparation increase costs.
• Cluster reliability and communication overhead: Failures and synchronization bottlenecks waste GPU time.
• Talent scarcity and research iteration: Specialized experts and repeated experiments add labor and compute expenses.

How to Reduce LLM Training Costs

LLM training costs fall when teams reduce unnecessary FLOPs, increase accelerator utilization, improve data efficiency, and scale infrastructure only after smaller experiments validate the model design.

• Mixture-of-experts, sparsity, and efficient attention: MoE activates only the model components needed for each token to reduce compute and memory use. Sparse layers and efficient-attention approaches can further lower memory and processing requirements.
• Mixed precision, optimized kernels, and parallelism: Use Q8, FP8, or quantization where suitable to improve throughput and reduce memory demand. Optimized kernels and parallel-training strategies keep GPUs productive.
• Data deduplication, curriculum learning, and synthetic data: Remove duplicate and low-quality data before training. Sequence data deliberately and use synthetic examples only with strong quality controls.
• Reserved capacity, spot instances, and GPU scheduling: Reserve GPUs for deadline-critical runs and use lower-cost spot capacity for interruptible workloads. Frequent checkpoints and automatic restarts reduce interruption risk.
• Progressive scaling, checkpoints, and early stopping: Test data, architecture, and throughput on small clusters before scaling. Checkpoints protect against failures, while early stopping prevents spending on underperforming runs.

Should Your Company Train Its Own LLM in 2026?

Most companies should train an LLM from scratch only when proprietary data, model behavior, or infrastructure control creates a clear strategic advantage that existing models cannot deliver economically. 

When proprietary pretraining creates strategic value

Proprietary pretraining can be justified when a company needs capabilities that available models cannot provide (e.g., specialized domain knowledge or unique language coverage). It is most defensible for organizations with large proprietary datasets, strong AI development teams, sustained compute budgets, and a clear multimillion-dollar business case.

When fine-tuning, RAG, or APIs deliver better ROI

• Fine-tuning is suitable when the business needs repeatable task behavior, specialized output formats, or brand-aligned responses.
• Retrieval-augmented generation (RAG) is usually better when knowledge changes frequently and answers must be grounded in current, attributable enterprise content. 
• Managed APIs or open-weight models are the fastest route when the priority is embedding AI into CMS, ecommerce, customer-service, or internal workflows. 

A build-vs-buy decision checklist

Before committing to proprietary LLM training, evaluate whether:

• Does proprietary data create a durable advantage that public models and RAG cannot reproduce?
• Is model ownership essential for product differentiation, data sovereignty, or regulatory compliance?
• Can the company fund the full lifecycle: pretraining, post-training, serving, evaluation, security, and continuous improvement?
• Does the organization have (or can it retain) specialists in LLM research, data engineering, MLOps, AI security, and governance?
• Can the expected business value justify a multi-year total cost of ownership, rather than only the initial GPU budget?
• Would a fine-tuned or open-weight model with RAG meet the accuracy, latency, privacy, and integration requirements sooner?

What Is the Future of LLM Training Economics?

LLM economics will likely split further: frontier pretraining will remain capital-intensive, while adapting capable models for specific enterprise use cases will become faster and less expensive. 

• Hardware efficiency and accelerator competition: New accelerators, lower-precision training, and better distributed-training software should improve performance per dollar. However, large training clusters will still require costly networking, power, cooling, and engineering expertise.
• Data constraints and licensing pressure: High-quality public text is becoming harder to obtain, while copyright rules and transparency expectations are increasing pressure to document training-data sources.
• Open-weight competition and falling adaptation expenses: More capable open-weight models give enterprises practical alternatives to building foundation models. Parameter-efficient techniques such as LoRA enable organizations to adapt a pre-trained model by training relatively small additional components, helping reduce adaptation compute and storage requirements.

Why Choose SaM Solutions for AI Development?

With SaM Solutions, businesses easily move from AI concepts to production-ready software. We combine AI consulting, AI proof-of-concept development, enterprise integration, and long-term support. Our experts build LLM-powered applications, contextual search, AI agents, automation, and predictive solutions that connect with existing CMS, ecommerce, CRM, ERP, and data platforms, so businesses can validate value quickly and scale with confidence. 

Final Takeaway

The cost of training LLM from scratch is a major business investment driven by compute, data, talent, testing, and operations, not GPU time alone.

For most companies, fine-tuning, RAG, APIs, or open-weight models offer faster, lower-cost value. Build from scratch only when proprietary data and long-term control justify the investment.

_{No time to read? Listen to the podcast:}

(Prefer videos? Watch a brief summary of this article below.)

A secure content management system (CMS) protects far more than web pages: it safeguards customer data, brand reputation, revenue-generating digital experiences, and the continuity of online operations. 

Umbraco CMS currently powers over 700,000 active websites worldwide, ranging from mid-sized businesses to Fortune 500 companies. Umbraco security provides a strong basis through built-in identity controls, configurable permissions, secure development practices, and ongoing vendor patches; however, real protection depends equally on how the CMS is configured, customized, hosted, and maintained.

Is Umbraco Secure?

We can say that Umbraco CMS is one of the most secure open-source content management systems, provided that an organization runs a supported version, applies security updates in a timely manner, and puts the right controls around access, infrastructure, and custom code. 

Technology executives tend to be skeptical of open-source software because they believe that the accessibility of source code makes it an easy target for hackers. However, the CVE (Common Vulnerabilities and Exposures) record of Umbraco is very low.

This content management system is based on ISO 27001-certified operational standards and automated static code analysis in release cycles. It is also backed by a dedicated Security Response Team that works with Microsoft’s .NET engineering community.

Explore our practical guide on how SaM Solutions’ experts upgraded from Umbraco 14 to 17

What Are the Most Common Umbraco Security Risks?

Umbraco provides authentication, authorization, file-validation, and hardening capabilities, but vulnerabilities can still emerge through legacy versions, insecure extensions, weak administrative access, custom integrations, and server misconfiguration.

Outdated CMS versions and packages

It is seldom the case that an outdated Umbraco installation is merely an inconvenience in terms of maintenance. Any vulnerabilities that have been disclosed are exploitable when security support is discontinued. For example, Umbraco’s August 2026 advisory identified four issues, including one high-severity vulnerability, but end-of-life versions 14–16 received no patch. 

Weak administrator credentials

A weak or recycled backoffice password can hand an attacker control over content, user roles, customer information, and core CMS operations. Accounts are more likely to be exposed when shared across teams, when former employees retain active credentials, or when password management is inconsistent across the organization.

Excessive user permissions

Not every editor needs to access every feature, language or website. Too broad permissions make things brittle, giving users access to content and administrative functions outside their responsibilities, increasing the chance of accidental changes and the damage that can be done by compromised accounts. Strict least-privilege access is particularly important for large, multilingual, multi-brand Umbraco environments.

Vulnerable custom code and exposed endpoints

Umbraco may be secure at its core while custom extensions quietly create gaps around it. APIs, forms, plugins, and third-party connectors become liabilities when authentication, authorization, or input validation is incomplete. Integrations with PIM, ERP, CRM, payment, and identity platforms widen the attack surface further, especially when secrets are poorly stored, external input is trusted, or endpoints are exposed without a clear business need.

Misconfigured servers and file access

Much more than intended can be exposed by a poorly configured hosting environment. Overly permissive file permissions, legacy TLS configurations, publicly accessible development tools, verbose error messages, or open backoffice access can expose administrative interfaces, configuration files, backups, uploaded content and cryptographic keys. Even a secure CMS cannot compensate for an insecure server beneath it.

Which Built-In Security Features Does Umbraco Provide?

Umbraco security focuses on authentication, access control, external identity integration, cookies, and data-protection mechanisms. 

Authentication and account lockout

Umbraco has separate password policies for backoffice users and website members. It can lock accounts after failed login attempts. The default lockout period is 30 days.

Role-based access control (RBAC)

Administrators can define user groups and restrict backoffice permissions to specific content areas and actions such as editing, publishing, translating or managing content.

Two-factor authentication

Umbraco offers configurable two-factor authentication for backoffice users and website members, including time-based one-time password apps like Microsoft Authenticator and Google Authenticator.

External login providers

Umbraco supports OAuth and OpenID Connect external login providers for both backoffice users and website members. Organizations can connect identity services such as Microsoft Entra ID, IdentityServer, Google, or Facebook.

Secure cookies and data protection

Umbraco uses cookies to support authenticated backoffice sessions, preview functionality, antiforgery validation, and visitor sessions. 

How Should an Umbraco Installation Be Hardened?

You can do it through layered controls that limit access, protect sensitive files, encrypt traffic, and reduce the amount of information exposed to attackers.

• Restrict backoffice access: Limit /umbraco access by IP range, VPN, or an identity-aware gateway.
• Protect configuration and system files: Keep secrets, keys, backups, and configuration outside public paths; apply least-privilege file and production access.
• Enforce HTTPS: Serve all public and backoffice traffic over HTTPS and redirect HTTP requests.
• Configure security headers: Use headers that mitigate browser-based attacks and reduce technology disclosure.
• Implement a Web Application Firewall (WAF): Block malicious requests, including XSS, SQL injection, automated scans, and abusive traffic, before they reach Umbraco.
• Implement a Content Security Policy (CSP): Restrict where the browser can load scripts, styles, images, frames, and other resources.
• Disable unnecessary development features: Remove detailed errors, diagnostic endpoints, test integrations, sample content, and unused APIs from production.

How Can the Umbraco Backoffice Be Secured?

Backoffice security best practices include strong authentication, limited permissions, controlled sessions, network restrictions, and quick account removal.

How Can Custom Code, APIs, and Integrations Be Protected?

A secure Umbraco solution validates every request, authorizes every sensitive operation, limits browser-based attack paths, and keeps dependencies and secrets under active control. 

• Input validation and output encoding: Validate all server-side input, including forms, URLs, APIs, webhooks, and uploads; encode output to prevent browser execution.
• API authentication and authorization: Authenticate non-public endpoints and authorize requests by role, tenant, content scope, and action.
• Cross-site scripting prevention: Encode output, sanitize HTML or rich text, and limit allowed browser scripts.
• Cross-site request forgery protection: Secure state-changing actions such as publishing, updates, approvals, and permission changes.
• Secure dependency and package management: Review and update Umbraco packages, NuGet libraries, JavaScript dependencies, and SDKs to reduce supply-chain risk.
• Secrets and configuration management: Store credentials and keys in a secrets-management system, separate production secrets from dev/test values, and rotate exposed credentials promptly.

How Should Umbraco Updates and Security Patches Be Handled?

Umbraco updates should follow a controlled lifecycle that identifies supported versions, evaluates security advisories, validates changes before release, automates routine patches, and preserves a tested recovery path. 

Tracking supported CMS versions

Maintain a live inventory of the Umbraco CMS version, .NET runtime, installed packages, custom integrations, and each component’s support status. 

Monitoring security advisories

Monitor official Umbraco security advisories and assess each notice against the exact versions and products used in the organization’s environment. 

Testing patches before deployment

Always test each Umbraco patch in a staging environment that mirrors production as closely as possible before pushing to live systems. The bigger the upgrade, the more important it is to stage it, because Umbraco migrations can change the CMS schema and data.

Umbraco also notes that moving across major versions may require upgrading through the nearest LTS major, rather than jumping to the latest release.

Upgrading from Umbraco 13 to 14: Our Journey from Build Errors to Breakthroughs

Creating automated update workflows

Automate routine patch delivery using CI/CD pipelines for repeatable, traceable updates and less reliance on manual changes in production.

Preparing rollback procedures

Before you deploy to production, you need to have rollback procedures in place. It may not be possible to roll back the database migrations and package changes safely by redeploying the previous build of the application.

How to Protect Content, Media, and Personal Data?

Secure upload handling, encryption, retention rules, recoverable backups, and access restrictions are key to protecting marketing content, member profiles, form submissions, product assets, customer documents, and commercially sensitive drafts.

• Access controls for sensitive content: Grant access only to named users and roles with a documented need; use Umbraco’s Sensitive Data group for protected member properties.
• Secure media uploads: Store uploads in a controlled, dedicated location and treat files as untrusted until server-side checks pass.
• File type and size validation: Check extension, MIME type, size, filename, and file signatures where needed; do not rely solely on client-side restrictions.
• Encryption and data retention: Use HTTPS for data in transit and protect sensitive stored data, keys, and secrets with appropriate encryption and storage controls.
• Backup protection and restoration: Encrypt backups, restrict administrator access, separate credentials, store copies securely, and test restoration regularly.
• Data minimization and privacy controls: Collect only necessary data and regularly audit forms, analytics, member fields, integrations, and media metadata.

How Is Umbraco Security Monitored and Tested?

An effective program combines centralized logging, automated alerts, routine scanning, secure-development testing, independent penetration testing, and rehearsed incident response. 

Application and access logging

Collect and centralize application, authentication, authorization and infrastructure logs to enable quick investigation of security-relevant events.

Suspicious activity alerts

High priority alerts should contain multiple failed backoffice logins, successful logins after lockouts, unanticipated privilege escalations, changes to authentication settings, large data exports, unusual API error rates, and modifications to critical configuration files.

Vulnerability scanning

Conduct authenticated vulnerability scans of the Umbraco application, hosting environment, operating system, network services, containers and exposed dependencies (weekly for internet-facing production systems).

Static and dynamic analysis of code

Perform static application security testing (SAST) before deployment to identify source-code issues such as hard-coded secrets, insecure APIs and vulnerable dependencies. Use dynamic application security testing (DAST) to detect vulnerabilities in the production application like missing security headers, broken access control, exposed endpoints, injection vulnerabilities and XSS.

Penetration testing

Penetration testing must be performed at least once a year. Also do it after major changes to uncover attack paths that automated tools might miss.

Incident response exercises

Test the organization’s incident response plan through scenario-based exercises. A tabletop exercise can simulate an Umbraco backoffice compromise, leaked API key, ransomware event, vulnerable package disclosure, or customer-data exposure.

What Should an Umbraco Security Checklist Include?

An Umbraco security checklist should turn security requirements into repeatable actions before launch, during routine operations, after changes, and during an incident. 

Checks before website launch

• Run Umbraco Health Checks and remediate critical findings
• Confirm the CMS, .NET runtime, and packages are supported and patched
• Enforce HTTPS, HSTS, security headers, and a tested CSP
• Enable MFA and least-privilege backoffice roles
• Protect secrets, data-protection keys, configuration, and backups
• Validate upload rules, APIs, integrations, logging, and alerts
• Test backup restoration and the incident-response process

Routine maintenance checks

• Review Umbraco security advisories and apply patches
• Check privileged users, inactive accounts, and permission changes
• Review failed logins, unusual access, API errors, and configuration changes
• Scan dependencies, infrastructure, and exposed endpoints
• Re-run Health Checks after meaningful changes
• Test backup recovery and incident contacts on a defined schedule

Checks after installing a package

• Verify publisher reputation, maintenance status, compatibility, and dependencies
• Scan the package for known vulnerabilities and exposed secrets
• Test it in staging before production deployment
• Review new APIs, permissions, scripts, cookies, and data flows
• Re-run Health Checks and regression tests after installation
• Document the package owner, version, update path, and rollback steps

Actions after a suspected compromise

• Contain the issue: disable affected access, revoke sessions, and block malicious IPs where appropriate
• Preserve logs, alerts, configuration snapshots, and other evidence
• Rotate exposed passwords, tokens, API keys, and secrets
• Assess affected data, users, integrations, and systems
• Patch the root cause, restore from a verified backup if needed, and validate the environment
• Document the incident and update controls, procedures, and monitoring rules

Is Umbraco Development by SaM Solutions Secure?

With SaM Solutions you get secure Umbraco development, as our experts integrate security into solution architecture, development, QA, deployment, and support services. Our teams build scalable web applications and APIs, perform full manual and automated testing, and provide post-launch updates, monitoring and optimization.

Summing Up

Securing an Umbraco CMS installation is a multi-layered task including authentication, infrastructure configuration, maintenance of core software, and reliable development practices. A well-thought-out Umbraco security strategy is the first line of defense for content-heavy corporate platforms or ecommerce ecosystems that keeps critical operational data and financial transactions out of malicious hands.

_{No time to read? Listen to the podcast:}

(If you prefer video content, please watch the concise video summary of this article below)

Migrating an enterprise-grade live search platform is never just about copying data from one system to another. It means keeping production fully operational while millions of records continue to change every day.

That was exactly the challenge our Customer faced when deciding to replace Elastic Cloud with AWS OpenSearch Serverless. The transition represented a fundamental shift from a node-managed, license-restricted ecosystem to an open-source, fully serverless architecture. The project required moving an extensive production dataset, adapting the application to a different search engine architecture, and ensuring that users experienced no downtime throughout the migration.

This case study explains how SaM Solutions’ engineers executed a zero-downtime migration strategy for a high-traffic customer support ticketing system and overcame several technical challenges unique to OpenSearch Serverless.

The Business Need

Our Customer provides a comprehensive ticketing platform used by businesses to manage customer support requests, knowledge bases, and internal wikis. 

The platform’s search functionality was based on the Elastic Cloud search engine. The setup was as follows:

• More than 10 logical indexes for multiple supported languages, resulting in 25+ physical indexes.
• Over time, these indexes grew to approximately 100 million records in production.
• Strict multi-tenancy requirements: To prevent data leaks between different enterprise accounts, the architecture enforced complex data filtering via Elastic index aliases so users could only view records authorized for their specific organization.

To optimize operational expenses and infrastructure costs, the Customer chose to migrate to AWS OpenSearch Serverless. However, as an active B2B SaaS platform, downtime was not an option. Since new tickets and knowledge base entries were continuously created, updated and deleted, they needed a solution that would keep both search platforms synchronized until the final cutover. 

Project Implementation

The core directive for SaM Solutions’ experts was clear: migrating live production data and ensuring the ability to switch between the two systems on the fly without data loss or user interruption.

Overcoming Technical Challenges

Although OpenSearch Serverless offers significant operational advantages, its architecture differs considerably from Elastic Cloud. Several implementation challenges required custom engineering solutions.

Results

The migration was completed successfully with no production downtime and no data loss.

Throughout the project:

• More than 100 million production records were migrated safely.
• Production indexing continued uninterrupted thanks to the dual-write synchronization mechanism.
• Historical data was transferred without affecting system availability.
• Extensive validation confirmed data consistency before the final cutover.
• Search functionality was fully adapted to AWS OpenSearch Serverless despite architectural differences.

The Customer was totally satisfied with the achieved results.

Summing Up

Large-scale search engine migrations are rarely straightforward, especially when production systems continue processing new data around the clock.

This project demonstrates that careful planning, incremental synchronization, and thorough validation can eliminate the risks traditionally associated with live infrastructure migrations. SaM Solutions’ team successfully moved a mission-critical search platform from Elastic Search to AWS OpenSearch Serverless without interrupting business operations. The transition was effectively invisible to end users. The platform remained fully operational during the entire migration process.

Need to tackle a similar challenge?

For organizations planning a similar transition, the biggest lesson is clear: successful migration means designing an architecture that allows both old and new systems to coexist safely until the very last switch.

Andrey Kopanev, Senior .NET Developer, AI Enthusiast

Let’s talk about your project

_{No time to read? Listen to the podcast:}

(If you prefer video content, please watch the concise video summary of this article below)

For years, European enterprises have relied on the US hyperscalers (Amazon Web Services, Microsoft Azure, and Google Cloud) to power their digital transformation. Choosing a cloud provider was primarily a technical and financial decision: companies compared computing power, managed services, global coverage, scalability, and price. But the ground beneath this infrastructure is shifting.

Driven by a wave of strict regulations, intensifying enforcement, and structural legal conflicts, European organizations are actively re-evaluating their dependency on US-headquartered cloud companies. Gartner forecasts that global sovereign cloud infrastructure spending will reach $80 billion in 2026, up 35.6% from 2025, with Europe recording 83% growth. 

Today, businesses are asking broader questions: 

• How much control do we retain over the infrastructure on which our operations depend? 
• Who can access business data and which laws apply to it? 
• How dependent operations are on a single supplier, and what happens if that relationship changes?
• How to ensure GDPR and CRA compliance?
• How to guarantee data security of European citizens?

This guide examines the reasons companies are reassessing their cloud strategies and moving from US to EU cloud providers, the available migration models, and the technical and commercial questions that should be answered before anything is moved.

The EU Regulatory Context

EU law does not prohibit European companies from using AWS, Microsoft Azure, or Google Cloud. It does, however, require closer scrutiny of where data is processed, which jurisdictions apply, how providers support critical operations, and whether the business can move its workloads when necessary.

Top Reasons European Companies Are Considering Cloud Repatriation

Cloud repatriation is rarely driven by one regulation or a single security concern. In most cases, it reflects a broader reassessment of cost, control, resilience, and long-term dependence on US hyperscalers.

Greater control over sensitive data

Companies in finance, healthcare, manufacturing, government, and other data-intensive sectors want clearer control over where sensitive information is processed, who can access it, and which laws apply. Moving selected workloads to an EU, private, or local environment can reduce legal and operational uncertainty.

Lower dependence on one provider

Applications built around proprietary databases, serverless platforms, identity services, or analytics tools can become difficult and expensive to move. Repatriation gives businesses an opportunity to replace some of these dependencies with more portable technologies and establish a realistic exit strategy.

More predictable infrastructure costs

Public cloud is cost-effective for variable demand, but not every workload is variable. Stable applications with predictable resource needs may be cheaper to run on dedicated, private, or local infrastructure. Companies are also reviewing egress fees, premium support, long-term commitments, and the cost of underused resources.

Stronger business continuity

Relying on one provider creates a concentration risk. Outages, service changes, contractual disputes, or geopolitical developments can affect systems far beyond the IT department. A hybrid or multi-provider model gives companies more options when a platform becomes unavailable or no longer meets business requirements.

Customer and procurement requirements

Public-sector buyers and regulated customers increasingly ask where data is stored, who operates the infrastructure, and how services can continue if a provider relationship ends. European or sovereign cloud options can help suppliers meet stricter tender requirements and demonstrate greater control over critical systems.

For most businesses, these reasons do not justify moving every workload. They do justify identifying which systems are too sensitive, costly, or strategically important to remain deeply tied to a single external provider.

Top Alternatives to AWS, Azure, and Google Cloud in Europe

Europe has no single provider that matches the full service catalog, global reach, and partner ecosystem of AWS, Azure, or Google Cloud. European alternatives to US cloud providers tend to be stronger in narrower areas: infrastructure hosting, data sovereignty, Kubernetes, private cloud, transparent pricing, or regional support.

The EU-based cloud providers below are not ranked. You can choose depending on the workload, required services, geographic reach, compliance obligations, and how much platform management the company is prepared to handle.

OVHcloud

France-based OVHcloud offers one of the broadest European cloud portfolios. Its services cover virtual machines, bare-metal servers, storage, managed databases, private cloud, networking, and managed Kubernetes. Public cloud resources are available across Europe and other international regions.

OVHcloud is a strong candidate for companies that need more than basic infrastructure but do not require the entire hyperscaler service catalog. Its combination of public cloud, hosted private cloud, and dedicated servers also suits hybrid architectures. Managed Kubernetes is available for containerized applications, including multi-availability-zone options for workloads that need greater resilience.

Scaleway

Scaleway is a French cloud and AI provider with cloud regions in France, the Netherlands, and Poland, alongside an expanding European footprint. Its services include compute, object and block storage, managed databases, Kubernetes, serverless containers, GPU infrastructure, and AI tools.

The platform is particularly relevant to cloud-native development teams. Its Kubernetes Kapsule service runs in several European regions, while its object storage supports the S3 API, making it easier to adapt applications that currently use Amazon S3. Scaleway also offers a managed Kubernetes model that can incorporate resources from other cloud or private environments.

Airbus, a major European aerospace corporation, is migrating 70 most critical applications from AWS to Scaleway under a drive to increase digital sovereignty.

IONOS Cloud

IONOS Cloud is a German provider offering compute, storage, networking, managed databases, Kubernetes, backup, disaster recovery, and private cloud services. Its European data-center locations include Germany, France, Spain, and the United Kingdom.

The platform is suited to companies looking for an enterprise infrastructure provider with German and European operations. Managed Kubernetes integrates with IONOS virtual data centers, while APIs allow teams to provision and manage compute, storage, networking, and managed services through CI/CD and infrastructure automation.

IONOS also offers private cloud options for workloads that require dedicated hardware or stronger isolation.

STACKIT

STACKIT is the cloud division of Schwarz Digits, part of the German Schwarz Group. Its portfolio includes virtual machines, networking, object storage, managed databases, Cloud Foundry, and the STACKIT Kubernetes Engine.

The provider is aimed mainly at European enterprises and public-sector organizations that place a high value on regional data control. Its Kubernetes service uses standard Kubernetes clusters and includes automated updates, repairs, and scaling. STACKIT also offers Confidential Kubernetes for workloads that require additional protection during processing.

Its service catalog is smaller than those of the US hyperscalers, but it can be a good fit for German and European companies that need core infrastructure and managed platform services without deep dependence on proprietary hyperscaler technology.

T Cloud Public

T Cloud Public, previously known as Open Telekom Cloud, is operated by T-Systems. Its infrastructure is hosted in Germany and the Netherlands and is based largely on OpenStack and other open technologies.

The platform provides virtual machines, bare-metal servers, storage, networking, relational databases, and other infrastructure services. T-Systems also offers managed container platforms based on technologies such as Red Hat OpenShift and SUSE Rancher.

T Cloud Public is particularly relevant to large enterprises, regulated organizations, and public-sector customers that need European operations, enterprise support, and hybrid-cloud integration. Its use of OpenStack can also reduce dependence on closed infrastructure APIs, although application portability still needs to be designed and tested.

Aruba Cloud

Aruba Cloud is an Italian provider with a European data-center network built around company-owned facilities in Italy and the Czech Republic. It offers virtual and dedicated servers, storage, managed Kubernetes, private cloud, backup, and hybrid-cloud services.

The provider is worth considering where migration includes both cloud-native and traditional infrastructure. Its managed Kubernetes service handles cluster infrastructure and security patching, while its managed hybrid-cloud offering uses Red Hat OpenShift. Aruba also provides dedicated GPU resources that can be connected to Kubernetes environments for AI, analytics, and rendering workloads.

This range makes Aruba a possible target for organizations that want European infrastructure together with hands-on managed services.

Hetzner

Hetzner takes a more infrastructure-focused approach. The German provider offers cloud servers, dedicated servers, block and object storage, load balancers, firewalls, and backup services. Its own European data-center parks are located in Germany and Finland.

Hetzner can be attractive for teams that want straightforward, competitively priced infrastructure and are comfortable managing more of the platform themselves. It is often better suited to virtual machines, self-managed Kubernetes, web applications, storage, development environments, and predictable server workloads than to applications that depend on a large catalog of managed databases, analytics, or AI services.

It should therefore be viewed as an infrastructure alternative rather than a direct functional replacement for AWS, Azure, or Google Cloud.

Migration Options: EU Cloud, Private Cloud, On-Premises, or Hybrid?

The target environment (public, sovereign, private, hybrid cloud, multi-cloud, or on-premises infrastructure) should be selected separately for each workload.

How to Migrate from AWS, Azure, or Google Cloud to an EU Cloud Provider

A cloud migration should begin with a clear understanding of why the company is changing providers, which systems should move, and what the new environment must deliver.

The Biggest Risks of Moving to an EU Cloud Provider

A US to EU cloud migration can reduce some risks while introducing others.

Key Decision Criteria Before Migrating

Before initiating a migration, your leadership team should address these four core questions:

1. How sensitive is our data? Classify your data. If you handle highly regulated financial data, critical healthcare metrics, or state contracts, a sovereign EU provider is highly compelling.
2. What are the refactoring costs? If you are deeply tied to proprietary hyperscaler databases, calculate the development resources required to decouple your software and move to open-source alternatives.
3. What are our uptime and latency requirements? Ensure the European cloud providers you evaluate have physical data centers situated close to your core users with robust service-level agreements (SLAs).
4. Do we have the internal skills? Managing a hybrid, multi-cloud, or localized infrastructure setup requires specialized DevOps and cloud architecture expertise. Do you have the talent in-house, or do you need a partner?

How SaM Solutions Can Help

Navigating the complexities of cloud sovereignty, code refactoring, and modern platform engineering requires deep, proven expertise. As a global software development company with over 30 years of experience and a strong geographical presence across the EU and US, SaM Solutions helps businesses successfully execute zero-downtime, compliant migrations.

Our specialized cloud and DevOps services cover every stage of your modernization journey.

• Sovereignty and readiness assessment: We audit your existing cloud infrastructure, map data flows, identify proprietary US cloud dependencies, and build a tailored migration roadmap.
• Cloud architecture and refactoring: Our certified engineers decouple your applications from proprietary APIs, redesigning them into modern, cloud-native microservices.
• Kubernetes and containerization: We containerize your legacy applications and deploy them using Kubernetes, ensuring complete portability across any European cloud provider.
• DevOps and infrastructure automation: We implement custom Infrastructure as Code (IaC) via Terraform and build secure GitOps CI/CD pipelines to ensure your operations are stable, repeatable, and vendor-agnostic.

Conclusion: Cloud Sovereignty Is a Workload Strategy

European businesses do not need to choose between blindly remaining on a US hyperscaler and immediately moving every system to an EU provider. The better approach is to understand the organization’s data, workloads, dependencies, legal exposure, continuity requirements, and long-term costs.

For some workloads, an AWS, Azure, or Google Cloud environment will remain the best option. For others, an EU cloud, sovereign environment, private platform, or local infrastructure may offer greater control and resilience. In many cases, a hybrid cloud provides the safest transition.

The most important step is to preserve the ability to decide. Applications should be designed so that a provider change is a manageable business project, not an emergency transformation triggered by circumstances outside the company’s control.