What is Umbraco Training like? What will you learn?

When I first signed up for Umbraco training, I wasn’t sure what to expect. Would it just be a run-through of documentation? A series of demos I’d forget a week later?

What I found instead was hands-on, practical, and directly tied to the kinds of problems developers actually face. From extending the back-office with custom tools, to structuring clean MVC templates, to integrating external systems and locking things down with security best practices — each step made me not just know Umbraco better, but use it better.

If you’ve ever wondered what Umbraco training is really like and what you’ll actually learn, here’s a look at the key lessons that stood out to me on the path to Expert Certification.

Extending the Backoffice

I already had a basic understanding of the back office and what could be done with it, but in this section I was able to expand that knowledge by working with extensions like Lit, Vite, and TypeScript to achieve even more.

I’ve always appreciated how clean and editor-friendly the interface is, but creating my own property editors, customizing the UI, and integrating the Umbraco UI Library gave me a whole new appreciation for its flexibility.

The challenge? Figuring out how to structure larger back-office extensions so they stay maintainable over time. I had to find the balance between “this is cool” and “this will still make sense six months from now.” My lightbulb moment was realizing how much you can streamline content workflows with just a few well-placed custom tools.

Quick example: a small Lit-based property editor for an “Alert banner” (toggle + text + theme) that editors can reuse anywhere, instead of hand-coding alerts in multiple views.

When to choose what

• Custom property editor: when editors repeat the same pattern across pages and need a single, reusable UI.

• Compose built-ins (e.g., Textbox/Dropdown/Media Picker): when requirements are simple and you want zero custom code.

• Dashboard/panel extension: when the tool spans multiple doctypes (e.g., content audits, bulk actions).

Trade-offs

• More power = more maintenance (bundle size, upgrades, testing).

• Document your folder structure and naming early; future you will thank you.

Umbraco and MVC

I’ve worked with MVC before, so this part felt familiar, but doing it in Umbraco with strongly typed models and clean controllers made me look at consistency in a new way.

What stood out to me was having so much control over rendering while still keeping things easy for editors. The tricky part was keeping templates flexible without overcomplicating them. Once I found that balance, it was really satisfying to see how clean and reusable the setup turned out.

Quick example: moving repeatable UI into a View Component and passing a typed model trimmed the Razor views and kept logic out of templates.

When to choose what

• RenderController + strongly typed models: page rendering with editor-owned content.

• SurfaceController: form posts or actions initiated from views (validation, feedback).

• API Controller: JSON endpoints for front-end apps/components.

Trade-offs

• Too many partials/components can fragment the mental model; group by feature, not by file type.

• Keep view models lean; map once in the controller, not in the view.

Application Integration

This part was really exciting because it showed how Umbraco can connect with other systems instead of just standing alone. I got hands-on with things like Algolia, HubSpot Forms, and Shopify, and it made me realize how easily Umbraco can become the main hub for almost anything.

The coolest moment was seeing Umbraco data show up in another service in real time. The hardest part was deciding how much data to actually send, it’s not just about connecting everything, it’s about knowing where to draw the line.

Quick examples

• Algolia: as-you-type results and typo tolerance (e.g., “Hary Poter” still returns Harry Potter).

• HubSpot Forms: a dropped-in form creates/updates a contact, triggers a welcome email, and assigns a sales task.

• Shopify: pulling product data into content pages without duplicating truth.

When to choose what

• Stay inside Umbraco: simple needs, low traffic, no external automation required.

• Use SaaS (Algolia/HubSpot/Shopify): when you need instant search, marketing automation, analytics, or robust commerce.

• Hybrid: store canonical content in Umbraco, push essentials out via webhooks or scheduled jobs.

Trade-offs

• External dependencies (uptime, APIs, pricing tiers).

• Privacy/compliance and field mapping discipline.

• Extra scripts/assets, watch page weight and defer where possible.

Security

Security has always felt a little overwhelming, but breaking it into smaller steps made it much more approachable. I learned how HTTPS, TLS, and certificates build the foundation for secure communication, and how easy it can be for threats like man-in-the-middle attacks or cookie misuse to expose vulnerabilities if protections aren’t in place.

Along the way, I configured HTTPS enforcement, explored security headers like HSTS, and dove deeper into protections against clickjacking, MIME sniffing, and different types of XSS. One of the biggest takeaways was implementing Content Security Policy (CSP) and Subresource Integrity (SRI). While working with multiple headers and CSP rules without breaking the site was challenging, it taught me that security isn’t just about turning on defenses, it’s about testing and adjusting to make sure everything works safely.

I also practiced hiding the Umbraco login page, setting up two-factor authentication, and applying least privilege with custom user groups. Each of these reinforced the idea that security is layered, no single step is enough, but together they make a site much harder to breach.

Quick example: starting with a conservative CSP (default-src 'self') and then explicitly allowing only the domains needed for images, scripts (with nonces), and fonts; adding SRI to any CDN assets.

When to choose what

• HSTS + HTTPS Everywhere: always; enable preload once you’re certain.

• frame-ancestors (CSP) vs X-Frame-Options: prefer CSP; keep XFO for legacy.

• Report-Only CSP first: collect violations, then enforce.

Trade-offs

• CSP maintenance grows with third-party scripts.

• Over-strict rules can break features, iterate in Report-Only and add integration tests.

• Usability vs. friction (e.g., 2FA) needs stakeholder buy-in.

Final Thoughts

By the end of training, I realized it wasn’t about memorizing features — it was about learning how to think with Umbraco. How to balance flexibility with maintainability. How to give editors more power without overwhelming them. How to connect Umbraco with the wider ecosystem while keeping security front and center.

For me, the biggest takeaway was confidence: knowing that I can approach complex projects with a toolkit of patterns, integrations, and safeguards that actually work in the real world.

So if you’re considering Umbraco training, my advice is simple: go for it. You’ll walk away with more than just certification: you’ll gain the experience and mindset to build cleaner, stronger, and more flexible solutions.