# UnDigital - Full Context > UnDigital is an Australian digital agency specialising in managed hosting for enterprise websites, website management services, security, and digital strategy for enterprise, government and growing businesses. Based in Sydney, Sunshine Coast and Ho Chi Minh City. ## About UnDigital UnDigital was originally founded as Impulse Digital over a decade ago by Andrew Cornale, later rebranding to UnDigital after gaining insights from advertising agency partnerships. The agency is co-founded by Andrew Cornale (CEO & Director of Experience) and Kristen Cornale (Co-Founder & Strategic Director). The team of 15 operates on a fully remote, four-day workweek model from offices in Sydney, Sunshine Coast and Ho Chi Minh City. **Mission:** To help people dream big by building and scaling positive digital experiences. **Key differentiators:** - No lock-in contracts - Focus on measurable KPIs and results - Official Silverstripe CMS Partner (10+ years) - HubSpot Agency Partner - Enterprise security and compliance expertise - 24/7 monitoring and support with 99.9% uptime guarantee --- ## Managed Hosting for Enterprise Websites UnDigital provides managed hosting for enterprise websites that demand reliability. Enterprise-grade hosting infrastructure with 24/7 monitoring, security and ongoing support to keep business-critical sites performing at their best. Whether a website was built by an agency, in-house, or with AI — UnDigital provides the managed hosting, security hardening and expert support that enterprise websites require. ### Service Delivery Models UnDigital delivers managed hosting under three engagement models. Each is scoped to the client's stack, traffic profile and SLA requirements. **Hosting + Management (recommended)** - Full-stack infrastructure and ongoing engineering under one accountable team - Single point of contact and a single SLA - Dedicated infrastructure with 24/7 monitoring - Security monitoring and incident response - CMS updates and security patches - Dedicated monthly support hours **Hosting Only** - Dedicated high-performance VPS and cloud infrastructure - For teams who maintain their own application in-house - SSL certificate management - Enterprise DDoS protection and WAF - Automated backups and restore testing **Management Only** - For clients bringing their own AWS, Azure or cloud hosting - Ongoing security patching on the client's existing infrastructure - CMS updates and dependency management - Performance and uptime monitoring - SLA-backed monthly support allocation ### Capability Tiers Four service tiers scale by traffic profile (Hosting + Management and Hosting Only) or by monthly support allocation (Management Only). Pricing is not published — every engagement is individually scoped and quoted. **Standard — up to 10k visits/month, or a 1 hour monthly support allocation** - Dedicated VPS infrastructure - 100GB SSD storage - SSL certificate management - Automated backups every 6 hours - Enterprise DDoS protection - WAF and anti-virus monitoring - 99.9% uptime guarantee (4 hour response SLA under Management Only) - CMS updates and security patches - 1 hour support allocation per month - Performance monitoring - Business-hours support desk **Growth — up to 50k visits/month, or a 3 hour monthly support allocation** - High-performance VPS infrastructure - 150GB SSD storage - SSL certificate management - Backups every 6 hours plus staging environment - Enterprise DDoS protection - WAF and anti-virus monitoring - 99.9% uptime guarantee (2 hour response SLA under Management Only) - CMS updates and security patches - 3 hours support allocation per month - Performance and uptime alerting - Priority support queue **Scale — up to 200k visits/month, or a 5 hour monthly support allocation** - Auto-scaling VPS / cloud infrastructure - 200GB SSD storage - SSL certificate management - Backups every 6 hours plus staging environment - Advanced DDoS protection - Managed WAF and CDN - 99.9% uptime guarantee (1 hour response SLA under Management Only) - CMS updates and security patches - 5 hours support allocation per month - Performance monitoring - 24/7 emergency response **Enterprise — 200k+ visits/month, or a custom support allocation** - Scalable multi-region cloud infrastructure (AWS) - Custom backup and disaster recovery strategy - SSL and certificate lifecycle management - Enterprise CDN + WAF - Advanced DDoS mitigation - 99.99% uptime guarantee (custom response SLA under Management Only) - Dedicated account manager - Custom monthly support allocation - 24/7 emergency response - Custom security policies - Quarterly strategy reviews ### Data Sovereignty - 100% Australian-hosted infrastructure and data residency - Low-latency routing to Sydney, Melbourne and Brisbane - 24/7 monitoring, alerting and emergency response ### Engagement Process Pricing is not published. Every engagement is scoped to the client's stack, traffic profile and SLA requirements, and begins with an infrastructure audit reviewing current hosting, security posture, performance and maintenance history. Enquiries are handled through https://undigital.com.au/contact — "Request an infrastructure audit" or "Speak to an engineer". There is no self-serve signup or checkout. --- ### Included Beyond Standard Hosting Two capabilities included with every managed hosting plan that volume hosts generally do not provide: continuous website uptime monitoring (external checks, alerting engineers with production access, per-site availability history) and continuous CVE scanning (every installed package matched against NVD and Ubuntu Security Notices). Both are reported in the client portal and neither is charged separately. See https://undigital.com.au/website-uptime-monitoring and https://undigital.com.au/cve-scanning-and-vulnerability-monitoring --- ## Agency Hosting Program (White-Label Managed Hosting & SLAs) UnDigital operates a partner program for creative, branding, UX and digital marketing agencies that build high-end client sites but do not want the operational load of post-launch hosting, maintenance, security incidents or after-hours emergency support. UnDigital acts as the invisible engineering and infrastructure team behind the agency: the agency offers enterprise-grade managed hosting, security and SLAs to its clients under its own brand, and UnDigital handles 100% of fulfilment. Page: https://undigital.com.au/agency-hosting Also known as: agency hosting, white-label hosting for agencies, agency reseller hosting, agency partner program (former name) ### Delivery Models **White-label** - The agency packages UnDigital SLAs into its own retainers - The agency bills its clients directly at its own markup and pays UnDigital wholesale rates - Clients do not speak to UnDigital; all updates, ticket resolutions and reporting are white-labelled under the agency brand or routed through the agency's account manager **Referral** - The agency refers clients to UnDigital for hosting and maintenance - The agency collects a recurring monthly revenue share - UnDigital handles client communication directly ### What the Agency Gets - **Zero distraction:** the agency's designers and senior developers stay on project builds instead of being pulled onto plugin crashes, staging errors or outages - **High-margin recurring revenue:** predictable monthly recurring revenue on every site launch by marking up wholesale SLA packages - **Enterprise security and SLAs:** 99.9%+ uptime, 24/7 monitoring, WAF, automated backups every 6 hours and guaranteed response times backing the agency's brand - **No cost of delivery:** no engineers to hire, no on-call roster, no monitoring stack to licence ### How It Works 1. **Choose a delivery model** — white-label or referral 2. **Onboarding and zero-downtime migration** — UnDigital engineers handle server provisioning, security hardening, SSL setup and migration, for new site launches or existing client portfolios 3. **Ongoing fulfilment** — 24/7 infrastructure monitoring, CMS updates, backups every 6 hours, and support handled within defined SLA boundaries ### Technical Coverage - **Enterprise CMS:** WordPress, Silverstripe, Drupal, Adobe Commerce / Magento - **Modern frameworks and headless:** Next.js, Node.js, Storyblok, Sanity, Craft CMS, Statamic, custom web applications - **Infrastructure and hosting:** AWS, Google Cloud Platform, Cloudflare Enterprise, dedicated VPS, Australian data centres ### Agency Hosting Program FAQs **Do clients ever speak directly with UnDigital?** In the white-label model, no — all communication is white-labelled under the agency brand or routed through the agency's account manager. In the referral model, UnDigital communicates with the client directly. **What happens if a client needs custom development outside the SLA?** The request is routed back to the agency's design and dev team so the agency can quote and bill the new project work. UnDigital can assist with scoped dev support on request. **Is there a minimum number of sites?** No minimums. An agency can start with its next site launch or migrate an entire legacy portfolio in bulk. **What does it cost?** Wholesale partner rates are not published. Rates depend on the platform, traffic profile and SLA tier each client site requires. The full rate card, margin bands and white-label SLA templates are shared on a partner call. ### Getting Started Partner enquiries are handled by booking a partner call with Andrew Cornale (CEO & Director of Experience) at https://house.undigital.com.au/book/andrew-cornale, or via https://undigital.com.au/contact. There is no self-serve signup. --- ## WordPress Hosting & Management UnDigital provides managed WordPress hosting and website management services for businesses of all sizes. Services include: - Dedicated WordPress-optimised hosting infrastructure - Australian data centres for fast local page loads - Automated 6-hourly backups with one-click restore - WordPress core, plugin and theme updates tested in staging before production deployment - Security hardening (file permissions, login protection, XML-RPC management) - Performance optimisation (caching, image optimisation, database tuning) - 24/7 uptime monitoring and incident response - SSL certificate management - Monthly performance and security reporting --- ## Silverstripe Hosting & Management UnDigital is an official Silverstripe Partner with more than 10 years experience in Silverstripe CMS development, hosting, maintenance and security. ### Process 1. **Silverstripe Audit** - Audit all website systems, integrations and functionality 2. **Silverstripe Migration** - Provision and migrate to dedicated hosting configured for Silverstripe CMS 3. **24/7 Service Level Agreement** - 99.9% uptime guarantee with 24/7 support 4. **Updates, Security & Bug Fixing** - Ongoing CMS updates and security patches 5. **Ongoing Maintenance & Reporting** - Continuous maintenance, reporting, improvements and new features ### Silverstripe Upgrade Services - Upgrading from SilverStripe 4 to SilverStripe 5 - Upgrading from SilverStripe 5 to SilverStripe 6 --- ## Drupal Hosting & Management Enterprise Drupal hosting and website management for complex, high-traffic sites. Services include: - Dedicated Drupal-optimised server configuration - Drupal core and module security updates - Performance tuning for high-traffic Drupal installations - Staging environments for safe update testing - 24/7 monitoring and incident response - Database optimisation and caching strategy - SSL and security hardening --- ## Custom & Headless Hosting Managed hosting for custom web applications, AI-built apps, headless CMS and modern frameworks. Platforms include: - Storyblok (headless CMS implementation and hosting) - Sanity (structured content, hosting and management) - Craft CMS (hosting, management, upgrades) - Statamic (hosting, management, upgrades) - Next.js (hosting, deployment, management) - Nuxt.js (hosting, deployment, management) - Custom PHP / Laravel applications - Node.js backends and APIs --- ## Magento / Adobe Commerce Hosting & Maintenance Managed hosting and maintenance for Magento and Adobe Commerce stores: - Magento-optimised server infrastructure - Core and extension updates - Security patching and PCI compliance support - Performance monitoring and optimisation - 24/7 uptime monitoring --- ## Website Security Services ### Content Security Policy (CSP) for Enterprise Websites Implementation and management of Content Security Policies to prevent XSS attacks and data injection on enterprise websites. ### Penetration Test Preparation Comprehensive preparation services for organisations undergoing security penetration testing, including vulnerability assessment and remediation. ### Improving Security Posture of Digital Platforms End-to-end security posture improvement for websites and web applications including vulnerability scanning, configuration hardening, and ongoing monitoring. ### MFA Implementation Multi-factor authentication implementation for website admin panels and user-facing applications. ### UpGuard Security Rating Improvement Services to improve and maintain UpGuard security ratings for enterprise organisations. ### Cloudflare for Enterprise Implementation and management of Cloudflare services including WAF, DDoS protection, CDN, and performance optimisation. --- ## CVE Scanning & Vulnerability Monitoring Continuous vulnerability monitoring for enterprise websites. Included with every managed hosting plan and every website support SLA at no additional cost — it is not sold separately or as an add-on. Page: https://undigital.com.au/cve-scanning-and-vulnerability-monitoring ### How It Works The software installed on every server UnDigital hosts or manages — operating system packages, language runtimes, libraries and CMS components — is inventoried and matched continuously against published vulnerability data. Results are reported in the client portal at house.undigital.com.au. No agent is installed, no scan window is scheduled, and no request load is placed on the website. ### Two Vulnerability Databases - **NVD (National Vulnerability Database)**: the global record of disclosed CVEs, indexed against upstream software versions. - **USN (Ubuntu Security Notices)**: Canonical's record of what has actually been fixed in Ubuntu's own packages. Both are read, because either alone produces a misleading report. Ubuntu backports security fixes into the version already installed rather than upgrading to a new upstream version, so the upstream version number never changes. Matching against NVD alone therefore reports vulnerabilities that the distribution patched weeks earlier, burying the real findings in false positives. Matching against the distribution feed alone misses everything installed outside the package manager — the CMS, its modules, and application dependencies pulled in at build time. ### Inventory Matching vs External Scanning Inventory matching examines what is installed rather than probing what responds to a request. It finds vulnerable components that are not exposed on a port — for example an image-processing library reachable only through a CMS upload form — which external scanning cannot see. It does not detect misconfiguration, exposed services or logic flaws, which is why it runs alongside perimeter controls and penetration testing rather than replacing them. ### What Is Reported - Every CVE affecting software actually installed, with severity and the published advisory - Installed version, fixed version, and whether the patch has been applied - Change over time, per server - Exportable records for audit and procurement evidence ### Compliance Uses - **Essential Eight**: evidence for the "patch applications" and "patch operating systems" mitigation strategies, both of which are assessed on patching speed and require a continuous record. - **ISO 27001**: demonstrable identification, assessment and remediation of technical vulnerabilities as an ongoing process. - **Cyber insurance and procurement questionnaires**: third-party evidence of vulnerability scanning frequency rather than self-assessment. - **Pre-penetration-test remediation**: clearing known CVEs first so test budget is spent on logic flaws rather than unpatched packages. ### Boundaries - It is not a penetration test and does not find business logic flaws or broken access control. - It is not a web application firewall and does not block traffic. - It does not patch automatically; patching production is scheduled, tested and reversible, performed by UnDigital on managed plans. - It cannot see software installed by hand outside the package manager on undocumented servers. ### Availability Included with managed hosting and website support SLA plans. Agencies in the Agency Hosting Program get it across their whole client portfolio under their own brand. Organisations hosting elsewhere access it through a management-only arrangement. --- ## Website Uptime Monitoring Continuous external availability monitoring for every website UnDigital hosts. Included with managed hosting and website support SLA plans at no additional cost — not a tier upgrade or an add-on. Page: https://undigital.com.au/website-uptime-monitoring ### The Distinction That Matters Standard web hosts monitor their own infrastructure: whether the server is running, whether the web service has crashed, whether their network is healthy. All of that can be true while a website returns an error to every visitor. Host status pages report on the host's network, not on an individual customer's application, so an incident affecting one site alone never appears on them. UnDigital monitors the website itself — checked continuously from outside the infrastructure, per site, the way a visitor experiences it. ### Why External Checking Checking from inside the server cannot detect a fault between the visitor and the server: DNS problems, network routing, CDN misconfiguration or certificate failures are invisible from the machine itself. External checks catch them. ### Failures That Server Monitoring Misses - **The site is up and broken**: half-completed deploys, exhausted database connection pools, full caches, 500 errors and timeouts on healthy hardware. - **Something expired**: SSL certificates, domain renewals, DNS records, API credentials. Nothing crashed; a date passed. - **Upstream dependencies**: third-party scripts, payment gateways or APIs stalling and hanging the page while the infrastructure is faultless. ### What Happens On Alert On managed plans an alert reaches engineers with production access, and severity determines the response. This is the substantive difference from standalone monitoring tools such as UptimeRobot or Pingdom: those perform the checking well, but the alert arrives in an inbox and the customer must still diagnose the fault and find someone able to fix it. Monitoring is the inexpensive half of the problem. ### Reporting Availability is recorded per site over time in the client portal at house.undigital.com.au, alongside CVE scanning reports. The record substantiates reliability claims for boards, auditors and clients, and is what makes an SLA uptime commitment measurable rather than merely stated. ### Relationship To SLAs Monitoring is the measurement; an SLA is the commitment defining how quickly somebody is obliged to respond, at what severity, and outside what hours. Organisations needing a contractual response commitment require both. --- ## Website Support SLAs for Enterprise & Government Guaranteed response times, uptime reporting, continuous monitoring, and predictable support built for high-risk organisations. - Severity-based tiered response protocols - 24/7 monitoring with proactive notifications - Rapid triage, escalation, and resolution procedures - Executive-level monthly metrics and performance reporting - Scalable retainer-based support - Comprehensive vulnerability management ### Process 1. Environment assessment 2. SLA tier definition 3. System integration 4. Monthly reporting delivery 5. Continuous optimisation --- ## Break/Fix & Emergency Website Support Emergency response services for website outages, security breaches, and critical bugs. Available 24/7 with rapid response times. --- ## Website Migration to New Vendor Managed migration services for organisations moving their website from one hosting provider or development agency to another, including DNS management, content verification, and zero-downtime transitions. --- ## Digital Strategy & Consulting Services ### Uncover (Strategy Phase) - Workshops - Goal Definition - Competitor Research - Customer Journeys - Infrastructure Planning - Technology Evaluation - User Research - User Journeys - Information Architecture - Prototypes and Data Flows - Market Research - Data Analysis - Performance Indicators - Audience Definition ### Create (Execution Phase) - Interaction Design - User Interface Design - Design Systems - Accessibility - Websites & Ecommerce - Web Applications - Mobile Applications (iOS & Android) - Platform Integrations - Chatbots & Automation ### Scale (Growth Phase) - Digital Marketing - Data Science - Reporting Dashboards - Lead Generation - Artificial Intelligence - Search Engine Optimisation - A/B Testing - Performance Optimisation - Conversion Optimisation --- ## Technology Stack **Frontend Frameworks:** - React, Vue.js - Next.js (SSR, SSG, ISR deployment and hosting) - Nuxt.js (Vue-based SSR and static site generation) **Backend & Runtime:** - Node.js (APIs, serverless functions, backend services) - PHP / Laravel - PostgreSQL (managed hosting, optimisation, replication, backups) - MySQL / MariaDB - MongoDB **Traditional CMS:** - WordPress - Silverstripe CMS (official partner) - Drupal - Craft CMS - Statamic **Headless & Modern CMS:** - Storyblok (headless CMS implementation and management) - Sanity (structured content, real-time collaboration) - Contentful (API-first content management) - Strapi (self-hosted headless CMS) **Ecommerce:** - Shopify / Shopify Plus - Magento / Adobe Commerce **Mobile:** - React Native (iOS & Android) - Native iOS & Android development **Infrastructure & DevOps:** - Vercel (Next.js deployment and edge hosting) - AWS (EC2, RDS, S3, CloudFront, Lambda, ECS) - Docker (containerised deployments) - Cloudflare (CDN, WAF, DDoS protection, Workers, DNS) - Dedicated Australian hosting infrastructure **Marketing & Analytics:** - HubSpot (agency partner) - Google Analytics, Google Ads, Meta - Hotjar, SEM Rush **Design:** - Figma, Adobe Suite --- ## Industry Specialisations & Results ### Government - Transport for NSW - Landcom Corporate ### Property & Real Estate - Sekisui House - enterprise digital ecosystem - Wisdom Homes - 600% increase in sales - West Village - retail marketing platform ### Corporate - Netflix - Australian Associated Press - Interrelate - Volvo Cars ### Ecommerce - OZ Design Furniture - 50% reduction in operational costs - My Milo - Map Coffee ### FMCG & Consumer - Pepsi Australia - Gatorade Australia ### Technology - HiPages Tradie - 200% increase in conversions - Unrealty - LuvLink App --- ## AI-Ready Infrastructure UnDigital provides hosting and production-readiness services for websites and applications built with AI tools. As more businesses build technology with AI, UnDigital provides the expertise in infrastructure, security, performance optimisation and ongoing management to get these projects production-ready and integrated into a business. Services include: - Infrastructure provisioning and configuration - Security hardening and SSL setup - CDN and performance optimisation - 24/7 monitoring and uptime guarantees - Ongoing maintenance and CMS updates - Strategic consulting on architecture and scalability --- ## Technical Resources ### Benefits of Cloudflare for Enterprise Websites URL: https://undigital.com.au/services/benefits-of-cloudflare-for-enterprise-websites **Improve performance, reduce risk, and simplify security across your digital platforms with Cloudflare — when it’s implemented and managed properly. We provide [Cloudflare Implementation Services](/services) to [Sydney, Brisbane and Sunshine Coast](/contact).** ##### Why So Many Organisations Research Cloudflare Cloudflare often enters the conversation when organisations are: - Experiencing performance issues or traffic spikes - Preparing for a security review or penetration test - Concerned about downtime or reliability - Managing multiple websites or online tools - Looking to simplify complex security stacks On paper, Cloudflare promises a lot. In practice, the benefits depend entirely on how it’s used. ##### What Cloudflare Actually Does (In Plain Terms) At its core, Cloudflare sits between your users and your website. This positioning allows it to: - Accelerate content delivery - Absorb and block malicious traffic - Filter and control requests before they reach your servers - Provide visibility into traffic, threats, and performance When configured correctly, it becomes a protective and performance-enhancing layer around your digital assets. ##### Key Benefits of Cloudflare for Enterprise Environments ###### 1. Improved Website Performance Cloudflare’s global network helps: - Reduce page load times - Improve user experience across geographies - Handle traffic surges without degradation For [enterprise and government websites](/specialisations), performance is not just UX — it’s credibility. ###### 2. Reduced Security Exposure Cloudflare helps limit: - Malicious traffic reaching your servers - Common attack vectors such as DDoS and bot abuse - Exploitation of known vulnerabilities This reduces risk before issues ever touch your application. ###### 3. Increased Website Reliability By absorbing traffic and filtering requests: - Infrastructure is protected during spikes - Outages caused by overload are less likely - Websites remain accessible during high-demand events Reliability is one of Cloudflare’s most underestimated benefits. ###### 4. Centralised Control and Visibility Cloudflare provides a single layer where organisations can: - Monitor traffic patterns - Identify suspicious behaviour - Apply security and performance rules consistently For teams managing multiple websites, this centralisation matters. ###### 5. Support for Compliance and Governance While Cloudflare is not a compliance solution on its own, it: - Supports broader security frameworks - Strengthens defence-in-depth strategies - Helps demonstrate proactive risk management This is particularly valuable in regulated and government environments. ##### Where Organisations Go Wrong with Cloudflare Despite its benefits, Cloudflare is often: - Enabled with default settings and left untouched - Treated as a “set and forget” security solution - Misconfigured in ways that cause hidden issues - Over-relied upon without supporting controls The result is false confidence — protection that looks good on paper but underperforms in reality. ##### How UnDigital Approaches Cloudflare We don’t treat Cloudflare as a product. We treat it as part of a wider security and reliability strategy. Our approach focuses on: - Aligning Cloudflare with your website architecture - Ensuring rules reflect real-world usage - Avoiding configurations that break applications or workflows - Integrating Cloudflare with monitoring, SLAs, and incident response This is where the real benefits appear. ##### Who Gets the Most Value from Cloudflare Cloudflare delivers the strongest outcomes for: - Enterprise websites with high visibility or traffic - Government and public-facing platforms - Organisations managing multiple domains - Teams under pressure to improve uptime and security - Websites exposed to unpredictable traffic patterns If you’re researching the benefits of Cloudflare, you’re likely already managing meaningful digital risk. ##### Common Questions **Is Cloudflare a security solution or a performance tool?** Both — but only when configured and governed correctly. **Can Cloudflare replace our existing hosting or security stack?** Not entirely. It complements infrastructure; it doesn’t replace responsibility. **Is Cloudflare useful for smaller or lower-risk sites?** Yes, but its value increases significantly with scale, complexity, and exposure. **Does Cloudflare guarantee protection from all attacks?** No. It reduces risk, not responsibility. ##### Next Step Cloudflare can be a powerful asset — or an underutilised checkbox. If you’re researching its benefits, the next step is understanding: - Whether it’s right for your environment - How it should be configured - How it fits into your broader digital security posture --- ### Break-Fix & Emergency Website Support URL: https://undigital.com.au/services/break-fix-and-emergency-website-support **Emergency support, technical troubleshooting, bug fixes, and rapid recovery for broken or compromised websites. We provide [Break-Fix & Emergency Website Support](/services) to [Sydney, Brisbane and Sunshine Coast.](/contact)** ##### When Things Break, You Can’t Wait [Enterprise](/specialisations) websites are complex. Plugins fail, APIs break, custom code misbehaves. You need a team that fixes the problem fast, without excuses. UnDigital’s break-fix service is designed for urgency and reliability, with experienced engineers who thrive under pressure. ##### What We Cover - CMS errors and crashes - Broken integrations & API failures - Malware infections and hacks - Performance degradation and downtime - Legacy system troubleshooting > “Our previous agency disappeared during a critical outage. UnDigital fixed everything within hours.” – IT Director, NSW Government ##### How It Works - Incident logged via SLA or direct contact - Triage and severity assessment - Immediate action & resolution - Post-incident analysis - Prevention recommendations ##### SLA & Response Times (Example) | Severity | Response | Resolution | | --- | --- | --- | | Critical | 15 min | 2 hours | | High | 30 min | 4 hours | | Medium | 1 hour | 1 business day | | Low | 4 hours | 3 business days | --- ### Content Security Policy (CSP) for Enterprise Websites URL: https://undigital.com.au/services/content-security-policy-csp-for-enterprise-websites **Reduce website attack surfaces, prevent malicious injections, and strengthen security posture with expertly designed and managed [CSP policies](/technology). We provide [Content Security Policy (CSP) for Enterprise Websites](/services) to [Sydney, Brisbane and Sunshine Coast](/contact).** ##### What Is a Content Security Policy (CSP)? A Content Security Policy (CSP) is a powerful security control that restricts where content on your website is allowed to load from. When implemented correctly, it dramatically reduces the risk of: - Cross-Site Scripting (XSS) attacks - Malicious script injection - Third-party compromise - Data exfiltration through unsafe sources When implemented incorrectly, it can break your website. That’s why CSP is widely recommended — and widely avoided — at the same time. ##### Why [Enterprises](/specialisations) Care About CSP CSP is not a “nice to have”. It is increasingly expected as part of: - Enterprise security frameworks - Government and regulated environments - OWASP-aligned security practices - Risk and compliance reviews - Penetration testing remediation Security teams look at CSP as a risk-reduction control. Digital teams often see it as dangerous and complex. Both are right. ##### The Problem with CSP in the Real World CSP is simple in theory and unforgiving in practice. Common enterprise pain points include: - CSP breaking analytics, tag managers, or marketing tools - Inline scripts and legacy code causing violations - Third-party platforms silently failing - No clear visibility into what should be allowed vs blocked - CSP being disabled after rollout due to instability The result? CSP becomes a half-implemented checkbox — or worse, abandoned entirely. ##### How UnDigital Approaches CSP We don’t treat CSP as a copy-paste header. We treat it as a living security control, designed around how your website actually operates. Our approach balances: - Security - Stability - Operational reality This is what makes CSP viable for enterprise and government environments. ##### Our CSP Services CSP Strategy & Design - Review of website architecture and asset loading - Identification of trusted vs untrusted sources - Alignment with OWASP and enterprise security standards - Policy design that supports real-world integrations CSP Audit & Risk Assessment - Review of existing CSP headers - Identification of unsafe directives - Analysis of CSP effectiveness vs perceived coverage - Risk-based recommendations (not theoretical ones) CSP Rollout & Monitoring - Report-Only policy configuration - Violation analysis and tuning - Gradual enforcement strategy - Ongoing monitoring and refinement CSP as Part of Ongoing Security Management - Integration with broader website security programs - Continuous review as websites evolve - Support for new tools, vendors, and platforms ##### Why CSP Matters at an Enterprise Level CSP reduces: - Attack surface - Reliance on fragile frontend trust - Impact of compromised third-party scripts For boards, executives, and auditors, CSP represents: - Proactive security posture - Demonstrable risk mitigation - Alignment with best-practice frameworks It turns your website from a soft target into a hardened asset. ##### Who This Is For Our CSP services are designed for: - Government departments and agencies - Enterprise organisations with complex websites - Digital teams managing high-traffic or high-risk platforms - Organisations that have failed a security review or pen test - Teams that know CSP is important but don’t want to break production If you’re researching CSP, you’re already in the right mindset. ##### How We Work - Understand your website, tools, and integrations - Assess current risk and CSP maturity - Design a CSP that fits your environment - Roll out safely using staged enforcement - Monitor, refine, and support long-term No guesswork. No generic policies. ##### Why UnDigital Most agencies: - Avoid CSP - Implement it once and walk away - Treat it as a purely technical exercise We don’t. UnDigital specialises in: - Enterprise websites - High-risk environments - Security controls that actually stick - Long-term reliability and governance CSP is one part of a much bigger picture — and we understand the whole system. ##### FAQs **Do we need CSP if we already have a WAF?** Yes. CSP and WAFs solve different problems. CSP protects the browser itself from executing malicious content. **Can CSP break our website?** Yes — if done poorly. That’s why careful design, testing, and staged rollout are critical. **Is CSP required for compliance?** It’s not always mandated, but it is increasingly expected during security reviews and penetration tests. **Is CSP a one-time setup?** No. Websites change. CSP must evolve with them to remain effective. ##### Next Step If you’re researching Content Security Policy, it usually means one of three things: - You’ve been advised to implement it - You’ve had a security review flag it - You’re proactively reducing risk We can help you do it **properly**. --- ### CVE Monitoring for Websites: From NVD Advisory to Patch URL: https://undigital.com.au/services/cve-monitoring-service-nvd-advisory-to-patch **This page explains the full chain of work between a CVE being published on the National Vulnerability Database and a tested patch running in production, and it is written for IT managers, digital leads and security teams who need that chain to actually close on a website they are responsible for.** #### A scan report is not vulnerability management Most organisations already have vulnerability data. It arrives as a weekly PDF from a scanning tool, a Nessus or Qualys export from the infrastructure team, an UpGuard score that dropped, or a dashboard with 340 findings and a red number at the top. The data is not the problem. The problem is that nobody owns the next step. A scanner tells you that a version string it fingerprinted matches a CVE record. It does not tell you whether the vulnerable code path is reachable in your configuration, whether the affected module is even enabled, whether a patched release exists for your major version, whether applying it breaks a template override, or who is going to deploy it on a Thursday night and be awake if the checkout stops working. Those are development and release-engineering decisions, not scanning decisions. This is where the usual split between a hosting provider and a website provider becomes expensive. The host will patch the operating system and refuse to touch the application. The agency that built the site will touch the application, but only when there is a project and a purchase order. A CVE in a CMS module sits precisely in the gap between them, and it sits there for months. #### Where CVE data actually comes from ##### The CVE Program and the NVD A CVE identifier is issued by a CVE Numbering Authority, which may be the vendor itself, a coordinating body or MITRE. The identifier and a description are published to the CVE List. The NVD, run by NIST, then enriches many of those records with CVSS scoring, CWE classification and CPE product ranges, which is what most scanners match against. Two practical consequences follow. First, a CVE can exist with no NVD enrichment yet, so a scanner that relies on CPE matching will not see it. Second, CPE ranges for CMS plugins and PHP packages are frequently imprecise or absent, which produces both false negatives and noisy false positives. Relying on the NVD alone gives you a late and partial picture of a website's real exposure. ##### Vendor and platform advisories The authoritative and earliest signal for website stacks is almost always the platform's own security channel. Drupal publishes SA-CORE and SA-CONTRIB advisories with its own risk calculator on scheduled Wednesday windows. Silverstripe issues security releases with CVE references and upgrade guidance per supported minor. WordPress core ships automatic security point releases, while the plugin and theme ecosystem is tracked through advisory databases rather than through core. Magento and Adobe Commerce issue APSB bulletins. Debian and Ubuntu publish DSA and USN notices that often backport fixes without changing the upstream version number a scanner is looking at. | Source | What it covers well | Where it falls short | | --- | --- | --- | | NVD / CVE List | Canonical identifiers, CVSS vectors, CWE mapping, broad coverage | Enrichment lag, weak CPE data for plugins and Composer packages | | Platform advisories (Drupal SA, Silverstripe, Adobe APSB) | Earliest accurate detail, affected versions, upgrade path | Only covers that platform; you must subscribe to each one | | Ecosystem databases (plugin and theme advisories, GitHub Advisory Database, FriendsOfPHP) | Third-party extensions that the NVD misses entirely | Varying quality; some entries never receive a CVE | | Distribution security notices (USN, DSA, RHSA) | Backported OS and PHP library fixes | Version strings stop matching upstream CVE ranges | | CISA KEV and EPSS | Real-world exploitation evidence and probability | Says nothing about whether your configuration is affected | #### You cannot monitor what you have not inventoried Accurate CVE monitoring starts with a software bill of materials for each site, refreshed automatically rather than written once in a spreadsheet. For a typical enterprise website that means resolving four layers. - **Application dependencies:** *composer.lock* and *package-lock.json* or *yarn.lock*, giving exact resolved versions rather than the ranges declared in the manifest. - **CMS extensions:** installed plugins, modules and themes with their versions, including anything installed outside the package manager or customised in place. - **Runtime and services:** PHP and Node versions and their extensions, nginx or Apache, MySQL, MariaDB or PostgreSQL, Redis, Elasticsearch, and the OpenSSL and libxml builds underneath them. - **Operating system packages:** the full dpkg or rpm manifest, plus any software compiled from source that no package manager knows about. On top of that you need to record what is internet-facing, what is behind a VPN or IP allowlist, which environments exist, and which code is forked. A fork is the single most common reason a patch cannot simply be applied, and the only cure is knowing about it before the advisory lands. #### Deciding what is genuinely urgent A list sorted by CVSS score is a poor work queue. CVSS describes intrinsic technical severity under worst-case assumptions. It does not describe likelihood, and it knows nothing about your deployment. Three signals used together produce a defensible order of work. | Signal | What it measures | How to use it | | --- | --- | --- | | CVSS base score and vector | Technical severity: attack vector, privileges required, user interaction, impact | Read the vector, not the number. AV:N/PR:N/UI:N on a public endpoint is a different problem to something requiring administrator rights. | | EPSS | Probability of exploitation in the wild in the next 30 days | Separates the thousands of theoretically nasty CVEs from the handful attackers are actually using. | | CISA KEV | Confirmed active exploitation | Treat presence in KEV as an immediate escalation regardless of the base score. | | Local context | Is the component installed, enabled, reachable and exposed? | Decides whether the finding is real work, a compensating-control decision, or a documented false positive. | The ACSC Essential Eight gives a useful external benchmark for the timeframes that follow triage: for internet-facing services, patch or mitigate within 48 hours where a working exploit exists, and within two weeks otherwise. If your current arrangement cannot demonstrate that for a CMS plugin, the gap is a process gap, not a tooling gap. #### Triage in practice Triage on a real website looks like a short sequence of questions, answered by someone who can read both the advisory and the codebase. - **Is the affected component present and at an affected version?** Lockfile and package manifest confirmation, not fingerprinting. - **Is the vulnerable code reachable?** A module installed but disabled, a REST route removed, or an unregistered form endpoint changes the answer. - **What privileges does exploitation require?** Unauthenticated remote code execution and an authenticated stored XSS available only to editors belong in different queues. - **What is exposed?** An administration path restricted by Cloudflare Access or an allowlist, with [multi-factor authentication](/services/why-your-website-should-have-mfa?stage=Stage) enforced, materially reduces urgency. - **Do compensating controls already block the known exploit pattern?** A WAF rule, a strict Content Security Policy, or upload restrictions can hold a line while a proper fix is scheduled. - **What does the fix cost?** A patch release, a minor upgrade, a major upgrade with breaking changes, or a code change to a forked module. Every one of those answers should be written down. The decision not to patch immediately is legitimate, but only if it is recorded with a reason, a compensating control and a review date. #### From patch decision to production Getting the fix live is where most vulnerability programs quietly fail. The work is ordinary release engineering, done under time pressure. - **Branch and build:** bump the dependency, resolve transitive conflicts, and let CI run unit, integration and static analysis checks. - **Staging verification:** deploy to an environment with production-like data, run database migrations, and check the specific functionality the patched component touches. Security releases that change escaping, session handling or file uploads break templates and integrations more often than any other kind. - **Regression checks:** smoke tests on forms, authentication, payment and search, plus visual comparison on key templates. - **Scheduled window versus out-of-band:** routine patches batch into a fortnightly or monthly window. KEV-listed and actively exploited issues go out immediately, with the rollback path confirmed and a restore point taken first. - **Verify and close:** re-scan, confirm the version in production, and record the change. A ticket closed without post-deployment verification is not closed. This pipeline is the reason CVE monitoring only works when it sits alongside deployment capability and a defined response commitment. That is exactly what a [website support SLA](/services/website-support-slas-for-enterprise-and-government?stage=Stage) exists to guarantee, and why patching under an SLA behaves differently to patching on a best-efforts basis. #### When there is no patch Sometimes the upstream fix does not exist, or exists only in a major version you cannot yet reach. Common cases are abandoned plugins, an end-of-life PHP branch, a CMS major version out of security support, or a fork that has diverged too far to merge. - **Remove the component.** The cheapest fix is frequently deleting a module nobody has used for three years. - **Backport the fix.** Apply the upstream patch to your pinned version and carry it as a documented local patch. - **Virtually patch at the edge.** A targeted WAF rule blocking the exploit signature buys time. [Cloudflare managed and custom rules](/services/benefits-of-cloudflare-for-enterprise-websites?stage=Stage) are effective for this, provided the rule is reviewed rather than left in place forever. - **Constrain exposure.** Restrict the affected path, disable the feature, or move administration behind an identity-aware proxy. - **Schedule the real remediation.** Virtual patching is a bridge to a platform upgrade, not a destination. If the underlying answer is a major version upgrade, plan it while the bridge holds. #### Evidence and reporting Auditors, cyber insurers, procurement teams and your own board are not asking whether you scan. They are asking whether findings are triaged, remediated within a stated timeframe and evidenced. Useful reporting includes a current asset and component inventory, a register of open findings with severity, decision and owner, time-to-remediate figures against policy, a change log tying each patch to a deployment and verification, and documented accepted risks with expiry dates. The same artefacts do double duty. They shorten a penetration test remediation cycle, they answer most of a security questionnaire without a scramble, and they feed directly into broader [website governance and risk management](/services/website-governance-compliance-and-risk-management?stage=Stage) obligations. #### Who owns this in your organisation right now Ask three questions internally. Who receives the advisory email for every platform and package your website depends on? Who decides, within 48 hours, whether a given CVE is exploitable in your configuration? Who deploys the fix, and under what agreed timeframe? If the honest answer to any of them is "the developers, when they have capacity" or "the host, I assume", the chain is broken at that link and it will stay broken until someone is contractually accountable for it. #### Frequently Asked Questions ##### What is a CVE monitoring service? A CVE monitoring service continuously matches the exact software running on your website and servers against published vulnerability data from the NVD, vendor advisories and ecosystem databases, then triages each match against your actual configuration. A managed service goes further by deciding exploitability, applying and testing the patch, and reporting the change. Monitoring without remediation capability only produces a longer list. ##### Is monitoring the NVD enough to cover a CMS website? No. NVD enrichment lags CVE publication, and CPE product data for CMS plugins, themes and Composer or npm packages is often incomplete or absent. Accurate coverage requires platform advisory feeds such as Drupal SA-CORE, Silverstripe security releases and Adobe APSB bulletins, plus ecosystem advisory databases and distribution notices from Ubuntu or Debian. ##### How quickly should a website vulnerability be patched? The ACSC Essential Eight benchmark for internet-facing services is to patch or mitigate within 48 hours where a working exploit exists, and within two weeks otherwise. In practice the queue should be ordered by exploitation evidence from CISA KEV and EPSS rather than by CVSS score alone, with anything actively exploited handled as an out-of-band release. ##### Why does a scanner report vulnerabilities that are not real? Scanners fingerprint version strings and match them to CPE ranges, so they flag components that are installed but disabled, code paths that have been removed, and backported distribution packages whose version numbers no longer align with upstream. Resolving these requires reading the advisory against the codebase and configuration. The correct outcome is a documented false positive, not an ignored ticket. ##### What happens when a vulnerable component has no fix available? The options are removing the component, backporting the upstream patch to your pinned version, virtually patching at the WAF or edge, or constraining exposure by restricting the affected path. Each of these is a temporary measure that should be recorded with a review date and paired with a scheduled upgrade to a supported version. ##### Can you provide CVE monitoring if our website is hosted elsewhere? Yes. Monitoring, triage and patching can be delivered as a management-only engagement on infrastructure you already own in AWS, Azure or another provider, or as part of fully managed hosting. Either way the engagement begins with an infrastructure and component audit, because an accurate inventory is the prerequisite for everything that follows. #### Managed CVE monitoring and patching with UnDigital UnDigital runs [CVE scanning and vulnerability monitoring](/cve-scanning-and-vulnerability-monitoring?stage=Stage) as a closed loop rather than a report: inventory, advisory monitoring across platform and ecosystem feeds, triage against your configuration, patch development, staging verification, production deployment and evidence. Because the same team holds the infrastructure and the application, there is no handover point where a finding can stall. It sits inside our wider [website security management and monitoring](/services/website-security-management-and-monitoring?stage=Stage) work, and the resulting patch register is usually the fastest way to shorten the remediation cycle after [a penetration test](/services/preparing-for-a-penetration-test?stage=Stage). Every engagement starts with an audit of what you are actually running, because that is the only honest starting point for a patch policy you can defend. --- ### Enterprise Drupal Hosting in Australia: What It Requires URL: https://undigital.com.au/services/enterprise-drupal-hosting-australia **This page explains what enterprise Drupal hosting in Australia actually requires at the infrastructure and application layer, and how to tell whether a prospective host can run Drupal or merely store it. It is written for IT managers, digital leads and agency owners responsible for a Drupal 10 or Drupal 11 site that matters to the organisation.** #### Why generic Australian hosting underserves Drupal Most Australian hosting offers are built around a filesystem and a database. You get a control panel, a PHP version selector, a nightly backup and a support desk that will restart services. That model works adequately for a brochure site. It fails for Drupal, because Drupal is not a set of files you upload. It is a Composer-managed application with a build step, a configuration system that lives in version control, a cron contract, a layered cache that must be invalidated correctly, and a published security advisory stream that requires someone to read it every Wednesday and act. The gap shows up the first time something goes wrong. A core security advisory lands, the host says patching the application is the client's responsibility, and the agency that built the site three years ago no longer has a retainer. Nobody owns the problem. The server is up, the SLA is technically met, and the site is running a version of Drupal with a known remote code execution path. For government and regulated clients that is also an Essential Eight failure, since the ACSC expects internet-facing applications with a known exploit to be patched within 48 hours. Hosting a Drupal site properly means owning the application layer, not just the box it sits on. Below is what that involves. #### Composer is the build system, so the deploy has to be a build Since Drupal 8, core and contributed modules are managed by Composer. The canonical production install is *not* what sits in your Git repository. The repository holds composer.json, composer.lock, custom modules and themes, and configuration YAML. The deployable artefact is produced by running composer install --no-dev --optimize-autoloader, which resolves drupal/core-recommended, pulls contributed modules into web/modules/contrib, writes vendor/, and runs drupal/core-composer-scaffold to place index.php, .htaccess and the default settings files. This is why FTP deploys break Drupal. Dragging files over an existing release leaves the autoloader describing classes that are no longer there, produces a composer.lock that does not match vendor/, and puts the site into a partially-updated state for however long the transfer takes. Worse, it skips the two steps that actually complete a Drupal release: drush updatedb to run database update hooks, and drush config:import to bring configuration into line with the code. A production-grade Drupal deploy looks like this, in order: - Build the release on a build agent, not on the web server, so a failed dependency resolution never touches production. - Ship the built artefact to a new, timestamped release directory. - Symlink the shared sites/default/files directory and settings.local.php into the release. - Put the site into maintenance mode only if the update hooks require it. - Run drush updatedb, then drush config:import, then drush cache:rebuild. - Atomically switch the document root symlink and reset OPcache. - Keep the previous release on disk so rollback is a symlink switch, not a restore. If a host cannot describe something close to this, they are not deploying Drupal. They are copying files and hoping. #### The docroot, settings.php and file permissions A Composer-managed Drupal project has a nested docroot, usually web/ or docroot/. Everything above it, including vendor/, composer.json and the configuration sync directory, must sit outside the web-accessible path. Hosts that insist on serving the repository root are forcing you to expose dependency source and configuration exports to the internet. Three permission details cause most of the real-world incidents we see: - **sites/default/settings.php** should be read-only to the web user after install, with credentials and environment-specific overrides in a separate settings.local.php that is never committed. If PHP can write to settings.php, any file-write vulnerability becomes a persistent backdoor. - **sites/default/files** must be writable by the PHP-FPM user and must never execute PHP. On nginx that means an explicit location block denying \.php$ under the files path, because the .htaccess protections Drupal ships only apply to Apache. - **Private files** belong in a directory outside the docroot entirely, with delivery routed through Drupal's file access system. Uploaded documents in government sites routinely contain material that should never be reachable by guessing a URL. #### PHP settings that actually matter under Drupal Drupal 10 requires PHP 8.1 or newer and performs best on 8.3; Drupal 11 requires PHP 8.3 or newer. Version alone is not the issue. The settings below separate a Drupal host from a generic LAMP host: - **memory_limit** of 256M as a working minimum, with higher ceilings for CLI so Composer and migration batches do not die mid-run. - **opcache.max_accelerated_files** raised well above the default. A Drupal install with a normal contributed module set easily exceeds 20,000 PHP files, and a default OPcache will silently stop caching the remainder. - **opcache.validate_timestamps=0** in production, paired with an explicit OPcache reset in the deploy pipeline. If the reset is missing, you will serve a half-old codebase after every release. - **realpath_cache_size** increased, because Drupal's file resolution is path-heavy. - **APCu** enabled for the class loader and Drupal's fast chained bootstrap cache. - On the database side, MySQL 8.0 or MariaDB 10.6+ with utf8mb4, InnoDB and READ COMMITTED transaction isolation. PostgreSQL is fully supported if that suits your environment better. #### Cron, queues and the tasks that fail silently Drupal's default automated cron fires on inbound page requests. On a production site that is the wrong mechanism: it adds latency to a real user's request, it does not run at all when traffic is low, and it is usually the first thing disabled when someone tunes performance. Production Drupal should run drush core:cron from system cron or a scheduler, on a defined interval, with the output logged. When cron stops, nothing visibly breaks. That is the danger. Search indexes stop updating, XML sitemaps go stale, temporary files are never purged, scheduled content never publishes, and, critically, the Update Status module stops checking drupal.org, so the site stops telling anyone that a security release exists. Sites have sat unpatched for months because a cron entry was lost during a server migration. Queue workers deserve the same treatment. If you use Search API with a Solr or Elasticsearch backend, a message queue, or any contributed module relying on advancedqueue, those workers need supervised processes with restart policies and alerting on queue depth, not a hope that cron drains them in time. #### The caching stack, and the invalidation problem Drupal's cache system is unusually good, provided the infrastructure respects it. Cache tags and contexts let Drupal tell an upstream cache exactly what to purge when a node changes. Most hosts ignore this and set a blunt time-to-live, which is why editors complain that their changes take 15 minutes to appear. | Layer | What it serves | Invalidation | Common failure | | --- | --- | --- | --- | | Internal Page Cache | Full pages for anonymous users | Cache tags, automatic | Disabled during debugging and never re-enabled | | Dynamic Page Cache and BigPipe | Partial pages for authenticated users | Cache tags and contexts | Custom code missing cacheability metadata, forcing max-age 0 | | Redis or Memcached | Render, entity and config cache bins | Tag-based, via the backend | Default database cache bins left in place, hammering MySQL | | Varnish | Edge HTTP cache | Xkey or ban on cache tags, via the Purge module | Fixed TTL with no tag purge, so content goes stale | | CDN (Cloudflare or CloudFront) | Static assets and HTML at the edge | Surrogate keys or URL purge on deploy | Aggregated CSS and JS cached across a release boundary | Getting cache tags flowing from Drupal through to the edge is a configuration exercise that takes a day and saves you from both stale content and origin overload. The same edge also carries your WAF rules and rate limiting, which is why we treat [Cloudflare as part of the hosting stack](/services/benefits-of-cloudflare-for-enterprise-websites?stage=Stage) rather than an optional extra. #### Security advisories and a real patch window The Drupal Security Team publishes advisories on a predictable schedule, with core releases on the third Wednesday of the month and contributed project advisories weekly. Each advisory carries a risk score out of 25 and an identifier: SA-CORE- for core, SA-CONTRIB- for contributed projects, PSA- for a pre-announcement warning you to have staff available. History makes the stakes obvious. SA-CORE-2014-005 and SA-CORE-2018-7600 were both exploited in the wild within hours of release. ##### Core versus contributed Core advisories are the ones people watch. Contributed modules are where sites actually get compromised, because the average Drupal site carries 40 to 80 contributed projects and only stable releases that have opted into the security advisory policy receive coverage at all. A module pinned to an alpha or a dev branch has no coverage, regardless of how well it works. A managed arrangement should define, in writing, how fast a highly critical advisory gets to production, who reviews the patch, who regression-tests it, and what happens at 2am on a Saturday. That is a function of your [support SLA](/services/website-support-slas-for-enterprise-and-government?stage=Stage), not your server specification. Running composer audit against the Packagist advisory database in CI and tracking PHP library CVEs through [continuous vulnerability monitoring](/cve-scanning-and-vulnerability-monitoring?stage=Stage) closes the gap between an advisory being published and someone noticing. #### Drupal 10 to 11, and what blocks it Drupal's release cadence means a major version arrives roughly every two years and the previous major loses security coverage soon after. Drupal 7 reached end of life in January 2025, and organisations that left it until the final quarter found the contributed module ecosystem had already moved on. The Drupal 10 to 11 move is a dependency and deprecation exercise rather than a rebuild. The work is: - Install the Upgrade Status module to produce an inventory of incompatible projects and deprecated API calls. - Run PHPStan with mglaman/phpstan-drupal across custom modules and themes, then apply Drupal Rector for the mechanical fixes. - Resolve the Symfony major version jump, which breaks custom event subscribers, service definitions and anything touching the HTTP kernel. - Check every contributed project for a Drupal 11 compatible release, and decide whether to patch, sponsor, replace or remove the ones without. - Verify the database and PHP versions meet Drupal 11 minimums before the code change, not after. Most of the elapsed time goes into contributed module readiness, which is exactly the work a host who only owns the server will not do. #### Environments, configuration sync and sanitised databases Drupal's configuration management system exports site configuration to YAML so it can move through environments in version control. It only works if the pipeline respects it. The sync directory belongs outside the docroot, environment-specific differences belong in Config Split, and anything genuinely owned by production editors belongs in Config Ignore. A deploy that does not run drush config:import is not deploying the site you tested. Production data flowing the other way needs the same discipline. Pulling a live database into staging without running drush sql:sanitize copies real user email addresses, hashed passwords and session data into a lower environment with weaker access controls. For Australian organisations handling personal information under the Privacy Act, that is a notifiable incident waiting to happen. Pair sanitisation with Stage File Proxy so lower environments pull files on demand instead of cloning a 60GB files directory. #### Backups, restore testing and recovery targets A Drupal site is three things that must be restored together: the database, the public and private files directories, and the code artefact with its exported configuration. A database-only backup gets you a site where every image is a broken link. A filesystem snapshot taken mid-write gets you a database that will not import. Ask for the numbers, not the adjective. What is the recovery point objective, in hours? What is the recovery time objective, in minutes, for a full restore to a working site? When was a restore last performed end to end, and to what environment? Hosts that have never tested a restore invariably discover on the day that the files directory was excluded from the job two years ago. Our standard enterprise arrangement runs six-hourly backups with retention and periodic restore verification, which is also the baseline we apply to [managed website hosting generally](/services/managed-website-hosting-australia-what-to-look-for?stage=Stage). #### What to ask a Drupal host before you sign | Capability | Shared or cPanel hosting | Unmanaged cloud VPS | Managed hosting with application ownership | | --- | --- | --- | --- | | Composer-based build and atomic release | No | You build it | Yes, in the pipeline | | Drush and CLI access | Rarely | Yes | Yes, and used operationally | | Who applies an SA-CORE patch | You | You | The host, inside an SLA window | | Contributed module tracking | Nobody | Nobody | Monitored against drupal.org advisories | | System cron running drush core:cron | Limited | You configure it | Configured and alerted on failure | | Redis or Memcached cache bins | No | You install it | Provisioned and tuned | | Restore tested to a working site | Unverified | Your responsibility | Verified on a schedule | | Drupal 11 upgrade capability | No | No | Yes, scoped as a project | If you are comparing providers formally, our guide to [evaluating a managed web services provider](/services/how-to-evaluate-a-managed-web-services-provider?stage=Stage) sets out the questions that separate the two columns on the right. #### Frequently Asked Questions ##### What does enterprise Drupal hosting in Australia need that standard hosting does not? It needs a Composer-driven build and deploy pipeline, CLI access for Drush, system cron running drush core:cron, a Redis or Memcached cache backend, tuned OPcache settings for a large PHP file count, and a named party responsible for applying Drupal security advisories. Standard hosting supplies the server and stops at the application boundary. The distinguishing factor is who owns the Drupal codebase after go-live, not the specification of the virtual machine. ##### Does Drupal hosting have to be in an Australian data centre? Not always, but for government and most regulated sectors it is a requirement rather than a preference, and procurement will usually ask where data is stored and processed. Hosting in the Sydney region also removes 150 to 250 milliseconds of round-trip latency for Australian users on uncached, authenticated requests, which is where Drupal admin performance is felt. Static assets can still be served globally from a CDN edge regardless of where the origin sits. ##### How quickly should a Drupal security advisory be patched? For a highly critical advisory on an internet-facing site, the ACSC Essential Eight expects patching within 48 hours where a working exploit exists, and within two weeks otherwise. In practice, core advisories released on a Wednesday should be assessed the same day, tested in a staging environment, and deployed to production within one business day. Contributed module advisories follow the same process but often require more regression testing because the module is interacting with custom code. ##### Can we keep our existing cloud account and still get managed Drupal hosting? Yes. A management-only arrangement is common where an organisation has an existing AWS or Azure commitment, enterprise agreement or internal security tooling it must keep using. The provider takes operational responsibility for the Drupal application, the deploy pipeline, patching, monitoring and backups while infrastructure continues to be billed to your account. The commercial model changes; the technical responsibilities do not. ##### How long does a Drupal 10 to Drupal 11 upgrade take? For a site with a moderate contributed module set and well-written custom code, the mechanical work is measured in weeks rather than months, with most of the effort going into contributed project compatibility and Symfony-related fixes in custom modules. Sites with heavily customised entities, abandoned contributed modules or a theme built against older frontend libraries take considerably longer. An Upgrade Status audit on the current codebase gives a defensible estimate before any work is committed. ##### What happens to our Drupal site if the agency that built it disappears? Provided the codebase is in Git with a working composer.lock and exported configuration, a competent Drupal team can take over without a rebuild. The risky cases are sites deployed by FTP with no repository, modules patched directly in web/modules/contrib without a patch file, and configuration changes made only in the production database. Those need a discovery and remediation phase before any normal maintenance cadence can begin. #### Talk to UnDigital about Drupal hosting and management UnDigital runs Drupal on Australian infrastructure and takes responsibility for the application as well as the server, which means the same team that keeps the uptime also applies the security advisories, runs the deploys, tunes the cache layers and plans the version upgrades. There is no gap between the hosting provider and the web team to fall into, because they are the same people. Every engagement starts with an infrastructure and codebase audit so the scope reflects the site you actually have. You can read more about [Drupal hosting](/managed-hosting/drupal-hosting?stage=Stage) and ongoing [Drupal website management](/managed-hosting/drupal-website-management?stage=Stage), or get in touch to arrange the audit. --- ### Enterprise Website Managed Services & Maintenance URL: https://undigital.com.au/services/enterprise-website-managed-services-and-maintenance **Performance, uptime, compliance, and structured monthly maintenance with clear SLAs and reporting. We provide [Enterprise Website Managed Services & Maintenance](/services) to [Sydney, Brisbane and Sunshine Coast](/contact).** ##### Websites Aren’t “Set and Forget” [Large organisations](/specialisations) need ongoing care: updates, monitoring, performance checks, backups, security. Small gaps lead to big problems. We provide full-service managed support that keeps your site fast, secure, and fully operational. ##### Our Managed Services Include - Website updates & [CMS](/technology) maintenance - Plugin & module management - Performance optimisation & caching - Security patching & monitoring - Backups & disaster recovery - Analytics & reporting for execs > “UnDigital’s managed services let us focus on business, not website firefighting.” – Director, OZ Design. ##### Process - Onboard & audit current website - Set up automated monitoring & backups - Implement security & performance optimisation - Scheduled maintenance & patching - Monthly reporting & continuous improvement --- ### How to Evaluate a Managed Web Services Provider URL: https://undigital.com.au/services/how-to-evaluate-a-managed-web-services-provider **A practical guide to evaluating a managed web services provider: the evidence to demand, the SLA clauses that decide whether the contract is worth anything, and the diligence questions to put in front of every vendor before you sign. Written for IT managers, digital leads and procurement teams responsible for a website that generates revenue or leads.** #### What you are actually buying when you buy managed web services Most managed web services proposals read the same way: monitoring, backups, updates, support. The words are identical across vendors. What differs is what happens at 2am on a Sunday when the checkout is returning 502s, and whether anyone in the vendor's team is allowed to open the codebase and fix the cause. Underneath the marketing, you are buying four separable things: - **Infrastructure operation.** Server provisioning, patching the OS and web stack, TLS certificate renewal, database tuning, backup execution and restore capability, firewall and DDoS posture. - **Application maintenance.** CMS core and module updates, dependency upgrades, PHP or Node runtime version moves, regression testing, deployment through a repeatable pipeline. - **Incident response.** Detection, triage, communication, remediation and a written post-incident record. - **Change capacity.** The developer hours to build the new form, integrate the CRM, fix the accessibility defect or ship the campaign template. A provider that only sells the first of those four is a host. A provider that only sells the fourth is a project agency. Enterprise website management means all four under one accountable party, and the reason to be strict during evaluation is that the gaps between them are where outages live. If you want a clean baseline for scope comparison, our breakdown of [what website managed services actually include and exclude](/services/website-managed-services-what-is-included?stage=Stage) is a useful checklist to hold each proposal against. #### The vendor gap: why hosting and website providers are rarely the same company The typical arrangement looks reasonable on a slide. A hosting company runs the server. A web agency built the site and does occasional work. An internal marketing team owns content. Everyone has a contract. Then the site slows to a crawl during a campaign. The host reports CPU at 90 per cent and says the application is issuing unbounded database queries, which is not their scope. The agency says the server has insufficient resources and no object caching, which is not their scope. Both are partly right. Neither is obliged to resolve it, and you are the only party with an incentive to. That standoff usually costs days, and days of degraded performance on a lead generation site is real revenue. This is the single most useful lens for evaluating any managed web services provider: **ask who is contractually responsible when the cause is ambiguous.** If the answer requires two vendors to agree, you have not removed the risk, you have documented it. #### Step one: document your own environment before you go to market Vendors can only quote against what you tell them, and vague briefs produce quotes that are re-priced three months in. Before the first call, assemble: - CMS and version for every site in scope, including microsites and campaign domains nobody has looked at for two years - Runtime versions: PHP, Node, Python, and the database engine and version - Where the code lives, whether there is a Git repository, and whether production matches it - Hosting arrangement: provider, account ownership, region, whether it is shared, VPS, or a cloud account you own - Integrations and outbound dependencies: CRM, payment gateway, ERP, email service, single sign-on, third party scripts - Traffic profile and peak events, and what a peak actually looks like in requests per minute - Compliance obligations: WCAG level, privacy, records retention, any penetration testing or security rating requirement - Current pain: the last five incidents, how long each took, and who resolved them That last item is the most valuable and the most commonly skipped. A vendor who reads your incident history and immediately names the likely root causes is demonstrating capability. One who does not mention it is quoting a template. #### Capability evidence to request, not just claims Every provider will say they monitor, back up and patch. Ask them to prove it with artefacts from existing clients, redacted as needed. | Claim | Evidence to request | What a weak answer looks like | | --- | --- | --- | | We take backups | Backup frequency, retention period, storage location, and the date and result of the last documented restore test | "Nightly backups" with no restore ever performed | | We monitor 24/7 | A sample alert, the escalation path, who receives it out of hours, and read access to the monitoring dashboard for your sites | Uptime checks only, no alerting to a human, no synthetic transaction checks | | We patch and update | A redacted maintenance report showing specific packages and versions applied, with dates | "Updates applied monthly" with no itemised record | | We have documented process | An actual runbook: restore procedure, rollback procedure, incident escalation, certificate renewal | Process described verbally, nothing written | | We deploy safely | The CI/CD pipeline, staging environment policy, and how a bad release is rolled back | Changes made directly on production over SFTP | | We track security | How CVEs affecting your stack are identified and triaged, and the last three acted on | "We use a security plugin" | | We keep change history | Git history, ticket history, and a change log you can read without asking | Work described in emails only | Two artefacts matter more than the rest: a **restore test with a date on it** and a **runbook you can read**. Backups that have never been restored are a hypothesis. Process that exists only in one senior engineer's head disappears when that engineer takes leave. #### Testing incident response during evaluation Put scenarios in writing and require written answers. You are testing whether the response describes actual mechanics or reassuring generalities. - The homepage returns HTTP 500 at 6:40pm on a Friday. Who is notified, by what mechanism, and what is the first action taken? - A critical CVE is published for our CMS core with a public exploit. What happens in the first 24 hours, and who authorises an emergency patch? - The database is corrupted at 11am and the last clean backup is six hours old. Walk through the restore, the expected duration, and what content is lost. - A third party integration starts timing out and page loads exceed 20 seconds. How is the failing dependency isolated? - Malicious file uploads are found in the web root. What is the containment sequence, and how do you determine the entry vector? - A deployment breaks the enquiry form and nobody notices for four hours. How would monitoring have caught it, and how is it rolled back? Good answers name tools, thresholds, roles and timeframes. Weak answers say the team would investigate promptly. It is also worth reading through [what a competent first hour of urgent website support looks like](/services/urgent-website-support-first-hour?stage=Stage) so you can benchmark the responses you get. #### Reading the SLA properly ##### Response versus resolution Most CMS support SLAs commit to a response time only. A one hour response can mean an automated ticket acknowledgement. Ask what the target is for a fix, or at minimum for a workaround and a written cause, and whether that target is contractual or aspirational. If a provider will not commit to resolution targets, ask what their historical median time to restore service has been for severity one incidents. ##### Severity definitions Severity levels decide which clock applies, so who classifies an incident matters enormously. Insist that severity is defined by business impact rather than technical category, that you can escalate a classification, and that specific examples are written into the schedule. A broken payment path and a broken sitemap should never share a tier. ##### Coverage windows "24/7 monitoring" and "24/7 response" are different products. Confirm the hours during which a human will act, the time zone those hours are expressed in, whether public holidays are included, and which state's holidays apply. For retail, confirm coverage across your peak trading period explicitly. ##### Exclusions and service credits Read the exclusions before the commitments. Common carve-outs include third party outages, DNS you control, upstream cloud provider incidents, content changes made by your team, and any planned maintenance window. Service credits are usually capped at a portion of the monthly fee, which means they are a governance signal rather than compensation. What matters is whether a breach triggers a formal review and remediation plan. Our guide to [website support SLAs for enterprise and government](/services/website-support-slas-for-enterprise-and-government?stage=Stage) sets out how these schedules are normally constructed, and there is a companion piece on [what to do when an SLA is breached](/services/website-sla-breach-what-to-do-next?stage=Stage). #### Commercial structures compared | Structure | Best suited to | Main risk | Watch for | | --- | --- | --- | --- | | Monthly managed retainer | Sites where uptime and security are the priority and change volume is steady | Paying for capacity you do not consume in quiet months | Whether the retainer includes development hours or only maintenance | | Prepaid hour blocks | Organisations with irregular project work on top of a maintenance base | Hours expiring unused, or being consumed by admin | Expiry terms, rollover, and minimum billing increments | | Per-site fixed fee | Multi-site estates with similar builds | Complex sites subsidised by simple ones, then re-priced | How a site is reclassified when traffic or complexity grows | | Time and materials | Low-stakes sites with no SLA requirement | No incentive to prevent recurring faults | Whether after-hours work carries a loaded rate | | Infrastructure at cost plus management fee | Organisations that own their own AWS or Azure account | Split responsibility if the cloud account is not fully delegated | Who holds root, and who can change billing-relevant resources | Time and materials deserves particular scepticism for a critical site. It pays the vendor for recurrence and gives them no financial reason to eliminate the cause of repeat faults. #### Access, ownership and exit The clauses you will care about most are the ones you hope never to use. Establish before signing: - **Code.** You own the repository, in your organisation's Git account, with the vendor as a collaborator. Not the reverse. - **DNS.** Your registrar account, your ownership, vendor granted delegated access. DNS held by a departing vendor is a hostage situation. - **Cloud accounts.** Either you own the account and delegate, or the vendor owns it and you have a written migration path with a defined timeframe. - **Backups.** The right to request a full database and file export at any time, in a documented format, without a fee. - **Documentation.** Runbooks, environment variables, integration credentials and architecture notes handed over at offboarding, not reconstructed after. - **Notice and assistance.** Termination notice period, and an obligation to provide reasonable transition assistance at agreed rates. If you are already locked into an arrangement without these, they can be recovered, but it is a project rather than an email. That is the substance of a [vendor replacement and transition](/services/website-vendor-replacement-and-transition-services?stage=Stage) engagement. #### Red flags that predict a difficult relationship - No staging environment, or changes described as "tested on production carefully" - Cannot produce a dated restore test - Refuses read access to monitoring or the ticket queue - Single named engineer with no documented backup or on-call rotation - Support only via a personal mobile or an individual's email address - Cannot describe how they would handle a CMS major version upgrade for your platform - Quotes without asking a single question about your integrations or traffic peaks - Owns your domain, DNS or repository as a matter of policy - Treats security as a plugin rather than a layered configuration - Talks about infrastructure but has no developers, or has developers but no infrastructure engineers #### A question set you can paste into an RFP - Which environments will exist, and how does code move between them? - What is monitored, at what interval, and what triggers a page to a human? - What is the backup frequency, retention and storage region, and when was the last restore test? - What is your recovery time objective and recovery point objective for a total server loss? - How are CVEs affecting our stack identified, and what is the patch window by severity? - Who is on call outside business hours, and how many people can resolve a severity one incident? - Define your severity levels with examples relevant to our site, and state who classifies an incident. - What are your response and resolution targets per severity, and what are the exclusions? - How many hours of development work are included, and what happens when we exceed them? - Who performs the work, in which locations, and are any parts subcontracted? - What reporting do we receive monthly, and does it itemise updates applied? - What is the offboarding process and the timeframe for handing over all assets? - Name two clients on the same CMS at similar scale that we can speak to. #### What a well-run first ninety days looks like Onboarding quality is the best available predictor of ongoing quality. A competent transition follows a recognisable shape. **Days 1 to 14.** Infrastructure and application audit. Full inventory of versions, dependencies, cron jobs, integrations and certificates. Access consolidated and secured with MFA. Monitoring and alerting stood up before anything is changed. **Days 15 to 45.** Backups configured and a restore proven in a scratch environment. Staging environment created. Code brought into version control if it was not already. Critical security findings remediated. WAF and DNS posture reviewed. **Days 46 to 90.** Deployment pipeline in place. Patch and update cadence running with itemised reporting. Runbooks written for restore, rollback and escalation. A prioritised remediation roadmap for the technical debt that cannot be fixed in the first month, with effort estimates. If a provider's onboarding plan is "we will take over the credentials and let you know if we see anything", that is your answer. #### Frequently Asked Questions ##### What is a managed web services provider? A managed web services provider takes ongoing responsibility for the operation of a website, covering the hosting infrastructure, the CMS and application layer, security, monitoring, and incident response under a defined service level agreement. It differs from web hosting, which covers the server only, and from project-based web development, which ends at launch. The distinguishing feature is that one party is accountable for availability regardless of whether the cause sits in the server or the code. ##### What should a CMS support SLA actually commit to? At minimum it should define severity levels with worked examples, response targets per severity, the hours during which a human will act and in which time zone, escalation contacts, and the exclusions that suspend the clock. Better agreements also commit to resolution or workaround targets, restore point and restore time objectives, and a formal post-incident review for severity one events. Service credits are useful as a governance trigger, but they rarely compensate for the commercial impact of an outage. ##### How do I know whether a provider's backups actually work? Ask for the date and outcome of the most recent restore test, performed into a separate environment rather than over production. A provider running proper backup discipline will have this documented, along with retention periods, storage location and the recovery point objective. If no restore has ever been performed, the backups are untested and should be treated as unverified. ##### Should hosting and website management come from the same vendor? For any site that drives revenue or lead generation, yes, because most serious incidents involve both layers. When a host and a developer are separate companies, ambiguous causes such as slow queries, memory exhaustion or caching conflicts produce a standoff where neither party is contractually obliged to resolve the issue. A single provider with both infrastructure engineers and developers removes that gap. ##### What should I own rather than let a provider hold? You should own your domain registration and DNS, the Git repository containing your code, and ideally the cloud account if you are on AWS or Azure, granting the provider delegated access to each. You should also have a contractual right to request a full database and file export at any time. Ownership of these assets is what makes changing providers a project rather than a negotiation. ##### How long does it take to move to a new managed services provider? A single well-documented site with clean version control can transition in two to four weeks including a migration and DNS cutover. Estates with undocumented servers, no repository, mixed CMS versions or live integrations typically take six to twelve weeks, with the audit phase consuming the first fortnight. The variable is rarely the migration itself, it is discovering what is actually running in production. #### Where UnDigital fits UnDigital operates as both the infrastructure provider and the development team, which is the arrangement this entire evaluation process tends to point towards. Our [managed hosting for enterprise websites](/managed-hosting?stage=Stage) covers dedicated Australian infrastructure, 24/7 monitoring, six-hourly backups, WAF and DDoS protection and uptime SLAs, and the same team maintains the WordPress, Silverstripe, Drupal, headless and custom applications running on it. For organisations bringing their own cloud account, we also deliver management only. Every engagement begins with an infrastructure and application audit, so the first thing you receive is a documented view of what you actually have, and our [enterprise website managed services](/services/enterprise-website-managed-services-and-maintenance?stage=Stage) page sets out how the ongoing arrangement is structured from there. Bring your current SLA, your incident history and the list of things nobody has been willing to own, and we will tell you what we would change in the first ninety days. --- ### Improving the Security Posture of Your Digital Platforms URL: https://undigital.com.au/services/improving-the-security-posture-of-your-digital-platforms **Reduce risk, strengthen resilience, and build confidence across your digital ecosystem with a structured, enterprise-grade security approach. We provide [Security Posture Services](/services) to [Sydney, Brisbane and Sunshine Coast](/contact).** ##### What “Security Posture” Really Means Security posture isn’t a single control, tool, or checklist. It’s the overall strength, readiness, and resilience of your digital environment — including: - Websites and [CMS platforms](/technology) - Third-party tools and integrations - Hosting and infrastructure - Operational processes and governance - People, access, and response capability A strong security posture doesn’t just prevent attacks. It reduces impact, speeds recovery, and builds organisational confidence. ##### Why Organisations Are Actively Researching This Most organisations don’t start here because “nothing’s wrong”. They start because: - A pen test or audit is approaching - A security review flagged weaknesses - A breach happened elsewhere in their industry - The board asked hard questions - Responsibility shifted to a new digital or IT leader Improving security posture is usually about reducing uncertainty as much as reducing risk. ##### The Hidden Risk of Point Solutions Many organisations try to improve security by adding tools: - A WAF - A scanner - A plugin - A policy Individually, these help. Collectively, without structure, they create false confidence. A strong security posture comes from alignment, not accumulation. ##### Common Gaps We See in Enterprise Environments Even mature organisations often have blind spots: - Outdated CMS platforms that “still work” - Third-party tools with excessive permissions - Inconsistent patching and updates - Limited visibility into real-world risk - No clear ownership during incidents - Security controls that exist on paper but not in practice These gaps rarely cause immediate failure — but they increase exposure over time. ##### How UnDigital Approaches Security Posture We don’t start with tools. We start with context. Our approach focuses on: - Understanding how your digital environment actually operates - Identifying where risk concentrates, not just where it exists - Aligning security controls with business reality - Creating systems that hold up under pressure Security posture is about preparedness, not perfection. ##### Our Security Posture Services Digital Environment Assessment - Review of websites, platforms, and integrations - Identification of high-risk assets and dependencies - Visibility into third-party exposure Security Maturity & Risk Review - Assessment of current controls and processes - Identification of gaps between intent and reality - Prioritised, risk-based recommendations Operational Security & Readiness - Incident response planning - Monitoring and escalation alignment - Backup, recovery, and continuity considerations Ongoing Security Management - Continuous review as platforms evolve - Support for audits, pen tests, and compliance - Long-term reduction of technical and security debt ##### Why This Matters at an Enterprise Level For leadership teams, improving security posture means: - Fewer surprises - Clearer accountability - Demonstrable risk reduction - Stronger audit and compliance outcomes - Confidence in digital operations It turns security from a reactive function into a managed capability. ##### Who This Is For This service is designed for: - [Government agencies and departments](/specialisations) - [Enterprise organisations](/specialisations) with complex digital ecosystems - Teams managing multiple websites or platforms - Organisations preparing for audits or penetration testing - Leaders accountable for digital risk If you’re researching how to improve security posture, you’re already thinking beyond quick fixes. ##### Common Questions **Is this the same as a security audit?** No. Audits identify issues at a point in time. Security posture focuses on sustained resilience. **Do we need to change platforms or tools?** Not always. Many improvements come from better structure, governance, and alignment. **Is this only about websites?** No. Websites are often the most visible risk, but posture includes the wider digital ecosystem. **How long does it take to improve security posture?** It’s not a one-off project. Meaningful improvement is staged and continuous. --- ### Improving Your UpGuard Security Rating URL: https://undigital.com.au/services/improving-your-upguard-security-rating **If your [UpGuard](https://www.upguard.com/) score has dropped — or is being questioned by customers, partners, or auditors — it’s critical to address the root causes properly, not just chase green ticks. We provide [UpGuard Support Services](/services) to [Sydney, Brisbane and Sunshine Coast](/contact).** ##### Why Organisations Start Searching for UpGuard Help Most organisations don’t look for help with UpGuard unless something has triggered it, such as: - A customer security questionnaire flagging a low score - A procurement or vendor risk review - A sudden drop in your UpGuard security rating - An upcoming audit or penetration test - Internal security teams raising concerns If you’re here, it’s likely UpGuard has surfaced issues that now need to be addressed quickly and correctly. ##### What an UpGuard Score Actually Represents An UpGuard security rating is not a single issue — it’s a signal. It reflects how your external digital footprint appears from a risk perspective, including: - Website configuration and exposure - Security headers and policies - SSL/TLS posture - Public-facing services and infrastructure - Known vulnerabilities and misconfigurations A low UpGuard score doesn’t necessarily mean your organisation is “insecure” — but it does mean there are visible weaknesses that others can see. ##### Why Fixing an UpGuard Score Is Not Straightforward This is where many teams struggle. UpGuard findings often: - Span multiple systems and vendors - Involve technical trade-offs - Conflict with legacy platforms or CMS limitations - Require careful remediation to avoid outages Attempting to “quick fix” issues without understanding impact can: - [Break websites or applications](/services/break-fix-and-emergency-website-support) - Introduce instability - Cause regressions in performance or functionality - Create false confidence rather than real improvement Improving your UpGuard score requires context, prioritisation, and experience. ##### Common Causes of a Low UpGuard Rating While every environment is different, we commonly see issues related to: - Outdated or unsupported platforms - Missing or misaligned security controls - Legacy configurations that no longer meet expectations - Assumptions that hosting providers “handle security” - Controls implemented without ongoing management UpGuard highlights the symptoms — it does not solve the underlying problems. ##### How UnDigital Helps Improve UpGuard Scores We don’t treat UpGuard as a checklist exercise. Our role is to: - Interpret findings in the context of your environment - Identify what actually matters vs what’s cosmetic - Improve your security posture without disrupting operations - Align remediation with enterprise SLAs and risk tolerance This approach leads to real improvements, not just short-term score inflation. ##### Our Focus: Sustainable Score Improvement We help organisations improve their UpGuard security rating by: - Strengthening website and application security - Improving reliability and configuration hygiene - Reducing unnecessary external exposure - [Supporting long-term governance](/services/website-governance-compliance-and-risk-management) and visibility The goal is not just a better score — it’s confidence when customers, auditors, or partners review your digital footprint. ##### Who This Is For This service is most relevant for organisations that: - Are already being monitored in UpGuard - Have enterprise or government customers - Are subject to vendor risk assessments - Manage public-facing websites or portals - Need to demonstrate [security maturity](/services/improving-the-security-posture-of-your-digital-platforms) If your UpGuard score is impacting deals, trust, or internal confidence — this is where we step in. ##### Common Questions **Is improving an UpGuard score just about ticking boxes?** No. Superficial fixes often backfire. Sustainable improvement requires understanding impact and risk. **Can a low score be fixed quickly?** Some improvements can be made efficiently, but lasting results require prioritised remediation. **Will improving our UpGuard score affect our website performance or users?** Not when done properly. Poorly implemented fixes are what cause disruption. **Do you work alongside internal IT or security teams?** Yes. We regularly collaborate with internal teams and third-party vendors. ##### Next Step If you’re researching how to improve your UpGuard score, the most important decision is who helps you do it. The right approach improves: - [Security posture](/services/improving-the-security-posture-of-your-digital-platforms) - Reliability - External trust - Internal confidence Without introducing unnecessary risk. --- ### Managed Website Hosting in Australia: What to Look For URL: https://undigital.com.au/services/managed-website-hosting-australia-what-to-look-for **A practical buyer's guide to managed website hosting in Australia: what "managed" should actually include, where most Australian hosts stop, and the operational inclusions to demand before you sign. Written for IT managers, digital leads and marketing managers responsible for a website that generates revenue or leads.** #### What "managed" actually means, and where most hosting stops "Managed hosting" is not a defined term. It is a marketing label applied to everything from a shared cPanel account with automatic WordPress updates to a fully operated cloud environment with a 24/7 on-call engineer. The word tells you almost nothing, so the only useful question is where the provider draws the boundary of responsibility. In most Australian managed hosting agreements, that boundary sits at the operating system. The provider will patch the kernel, keep PHP and the web server current, renew TLS certificates, take nightly snapshots and restore the server if the hypervisor fails. That is real work and it has real value. But it stops precisely where your risk begins. Consider what happens when a critical vulnerability is published for your CMS or one of its modules. The server is patched and healthy. The application is exploitable. Your host will tell you, correctly, that application updates are outside scope. Your web agency, if you still have one on retainer, may quote the work and schedule it for a fortnight's time. Meanwhile the CVE is being scanned for across the internet within days of disclosure. That gap between infrastructure and application is the single most common failure in Australian website operations, and it is almost always invisible until something breaks. #### The server boundary problem: who patches the application? Write down every layer of your stack and put a vendor name next to each one. A typical enterprise site looks something like this: - Network edge: CDN, DNS, WAF, DDoS protection - Infrastructure: compute instances, load balancer, managed database, object storage - Operating system: kernel, packages, TLS certificates, cron - Runtime: PHP or Node.js version, extensions, memory and process limits - Application: CMS core, modules and plugins, Composer or npm dependencies - Custom code: themes, templates, integrations, scheduled jobs - Content and configuration: user accounts, permissions, redirects, form handlers Most organisations can name a vendor for the top four and go quiet on the bottom three. When the person answering "who upgrades the CMS?" is a marketing manager with a credit card and a developer contact from three years ago, the site is unmanaged in every sense that matters. The test of a genuine managed service is whether the provider will take responsibility for a change they did not originally build. Upgrading a CMS minor release can break a third-party module. Bumping PHP can break a legacy integration. A provider who will only patch what cannot break is not carrying operational risk, they are avoiding it. Our breakdown of [what website managed services actually include, and what they do not](/services/website-managed-services-what-is-included) sets out where that line should sit. #### Data residency, latency and why Australian infrastructure matters There are three separate arguments for hosting in Australia and they are often conflated. ##### Legal and procurement requirements Australian Privacy Principle 8 in the Privacy Act 1988 governs cross-border disclosure of personal information, and government procurement frequently adds explicit data residency conditions on top of it. If your site collects enquiry forms, member records or job applications, where that data physically rests is a compliance question, not a preference. Ask which Australian region and availability zones your data sits in, and whether backups and logs stay onshore too. Backups leaking offshore is a common oversight. ##### Latency and Core Web Vitals Trans-Pacific round trip times are typically 150ms and up. For static assets a CDN hides most of that, but every uncached request, every authenticated page, every form POST and every database-backed API call pays the penalty in full. Sites with logged-in areas, portals or checkouts feel noticeably slower on offshore origins, and Largest Contentful Paint suffers where the document itself cannot be cached. ##### Support in your timezone A provider whose engineers are asleep during your business hours will hand you a ticketing system instead of a person. For a website that drives sales or lead generation, the practical difference between an AEST on-call rotation and an offshore follow-the-sun queue shows up on the day you need an emergency deployment. #### Inclusions checklist: what a managed hosting agreement should specify Vague scope is where disputes come from. Insist that the agreement names the following in writing. ##### Patching and upgrade windows Who patches the OS, the runtime and the application, on what cadence, and inside which maintenance window. What the emergency process is for a critical CVE outside that window. Whether upgrades are tested on a staging environment first, and who fixes the site if an upgrade breaks something. Continuous [CVE scanning and vulnerability monitoring](/cve-scanning-and-vulnerability-monitoring) is what turns a patching policy into something you can evidence to an auditor. ##### Backups, retention and restore testing Backup frequency, retention period, whether copies are stored off the production infrastructure, and the stated recovery point and recovery time objectives. Crucially: when was a restore last actually performed, and will they perform one on request? ##### Security controls WAF in front of the application with rules tuned to your stack rather than left at defaults, DDoS mitigation, TLS configuration and automated certificate renewal, enforced multi-factor authentication on CMS and server access, and file integrity monitoring. Ask who tunes WAF false positives when a legitimate form submission starts getting blocked. ##### Monitoring and response commitments What is monitored, from where, how often, and what constitutes an incident. Response and resolution targets by severity, published uptime commitment, and how service credits work. A 99.9% target allows roughly 43 minutes of downtime a month; 99.99% allows about four. Those are very different engineering commitments and should be priced as such. Our guide to [website support SLAs for enterprise and government](/services/website-support-slas-for-enterprise-and-government) covers how severity tiers are normally defined. ##### Change and access management Deployment process, rollback procedure, environment separation, who holds credentials, how access is revoked when staff leave, and whether you retain administrative ownership of DNS, the registrar and the cloud account. #### Comparison: shared hosting, cloud IaaS, managed hosting and managed hosting plus website management | Responsibility | Shared / reseller hosting | Cloud IaaS (self-run) | Managed hosting | Managed hosting + website management | | --- | --- | --- | --- | --- | | OS and runtime patching | Provider | You | Provider | Provider | | CMS core and module updates | Not covered | You | Usually excluded | Provider | | Fixing a site broken by an update | Not covered | You | Not covered | Provider | | WAF tuning and security response | Generic rules only | You | Varies, often generic | Tuned to the application | | Backup restore testing | Rarely evidenced | You | Sometimes evidenced | Rehearsed and documented | | Named uptime SLA | Marketing claim | Cloud provider SLA only | Yes, infrastructure scope | Yes, application scope | | Out-of-hours escalation to an engineer | No | Your team | Sometimes | Yes | | Best suited to | Brochure sites | Teams with in-house DevOps | Stable, low-change sites | Revenue or lead-critical sites | #### Backups that have actually been restored Every host takes backups. Far fewer can tell you the last time one was restored end to end, and that is the only number with any value. Untested backups fail for predictable reasons: the database dump was taken while a migration was mid-flight, user-uploaded files live outside the backup path, the snapshot captured an encrypted volume without the key, or retention quietly rolled the good copy off before anyone noticed the corruption. For a site that matters, ask for six-hourly database backups with copies held off the production infrastructure, a retention schedule you have agreed rather than inherited, and a documented restore rehearsal into a staging environment. If the provider cannot describe how long a full restore takes, you do not have a recovery time objective, you have a hope. #### Monitoring, alerting and who gets woken up at 2am Plenty of monitoring setups check whether the home page returns HTTP 200 every five minutes from a single location. That configuration will happily report a healthy site while the checkout throws a 500, the login form is broken, the CMS is returning cached pages from a dead database, or the TLS certificate expired an hour ago. Useful monitoring covers synthetic transactions through the paths that actually earn money, checks from multiple geographic points to avoid false alarms, content assertions rather than status codes alone, certificate and domain expiry, disk, memory and queue depth, and error rate thresholds from application logs. Then it needs an escalation path with a human at the end of it. [Uptime monitoring that actually detects outages](/services/website-uptime-monitoring-service) is the difference between finding out from a dashboard and finding out from your head of sales. Ask the direct question: at 2am on a Sunday, who receives the alert, what is their authority to act, and are they permitted to deploy a fix without waiting for your approval? #### Three engagement models Not every organisation wants to move infrastructure to get operational discipline. UnDigital delivers [managed hosting for enterprise websites](/managed-hosting) under three models. | Model | Infrastructure sits with | What we take responsibility for | Typical fit | | --- | --- | --- | --- | | Hosting + Management | UnDigital, on dedicated Australian infrastructure | Full stack: infrastructure, OS, application, security, monitoring, support SLA | Organisations that want one accountable vendor | | Hosting Only | UnDigital | Infrastructure, OS, backups, edge security and uptime, with your team or agency owning the application | Clients with capable in-house developers | | Management Only | Your own AWS, Azure or other cloud account | Operating the environment you already own: patching, hardening, monitoring, releases, incident response | Enterprises and government with mandated cloud tenancies | #### Questions to ask a prospective Australian host - Which Australian region holds the production data, and do backups and logs stay onshore? - Do you patch the CMS and its modules, or only the operating system? - If a patch you applied breaks the site, who fixes it and at whose cost? - When did you last restore a backup for a client, and will you demonstrate one for us? - Is the WAF tuned per application, and who resolves false positives on forms? - What are the response and resolution targets by severity, and what happens when they are missed? - Who is on call out of hours, in what timezone, and can they deploy a fix unilaterally? - Do we retain ownership of the DNS, registrar and cloud account? - What does an exit look like, and will you hand over a documented environment? If the answers arrive as a feature list rather than a named process, keep asking. Our longer framework for [how to evaluate a managed web services provider](/services/how-to-evaluate-a-managed-web-services-provider) turns these into a scorable checklist you can run across multiple vendors. #### Frequently Asked Questions ##### What does managed website hosting include in Australia? At minimum it should include provisioning and operating the server, operating system and runtime patching, TLS certificate management, backups with a stated retention period, and infrastructure monitoring with an uptime commitment. Most Australian providers stop there and exclude the CMS, plugins and custom code. If you need the application layer covered as well, that is website management and it must be scoped explicitly in the agreement. ##### Is managed hosting the same as a website maintenance agreement? No. Managed hosting covers the infrastructure the website runs on. A website maintenance or management agreement covers the application itself: CMS and module upgrades, security patches at the code level, performance work and content support. Buying one and assuming you have both is the most common reason an organisation discovers an unpatched CMS after an incident. ##### Does my website data have to be hosted in Australia? Not always, but Australian Privacy Principle 8 imposes obligations on cross-border disclosure of personal information, and government and enterprise procurement often mandates onshore residency outright. Onshore hosting also removes 150ms or more of trans-Pacific latency on every uncached request, which matters for portals, logged-in areas and checkouts. Confirm that backups and log data stay onshore too, not just the production database. ##### What backup frequency and retention should I expect? For a site that takes enquiries or orders, six-hourly database backups with copies stored off the production infrastructure is a reasonable baseline, with retention agreed against your recovery point objective. Nightly-only backups mean accepting up to a day of lost data. Whatever the frequency, insist the provider has performed and documented a full restore rather than simply confirming backups exist. ##### Can UnDigital manage hosting we already run on AWS or Azure? Yes. Under the Management Only model, the cloud account and billing stay with you and UnDigital operates the environment: hardening, patching, monitoring, release management, backup verification and incident response under an agreed SLA. This suits enterprises and government agencies with mandated cloud tenancies or existing committed spend. ##### What uptime SLA is realistic for an Australian website? A 99.9% monthly target permits roughly 43 minutes of downtime and suits most business-critical sites. A 99.99% target permits about four minutes and requires redundant infrastructure, automated failover and a fully staffed on-call rotation, which changes both the architecture and the cost. Check whether the commitment covers only the server or the website being genuinely available, and what service credits apply when it is missed. #### Talk to UnDigital about managed hosting Hosting providers and website providers are rarely the same company, and the gap between them is where outages, unpatched vulnerabilities and finger-pointing live. UnDigital runs both sides: dedicated Australian infrastructure with 24/7 monitoring, six-hourly backups, WAF and DDoS protection, plus the development capability to patch, upgrade and fix the application on top of it, across WordPress, Silverstripe, Drupal and custom web applications. Every engagement is scoped individually and starts with an infrastructure audit, so you get a written view of what is currently covered, what is not, and what it would take to close the gap. If you would rather not wait for the next incident to find out, including [emergency break/fix support](/services/break-fix-and-emergency-website-support) when something is already wrong, start with a conversation about your current arrangement. --- ### Preparing for a Penetration Test URL: https://undigital.com.au/services/preparing-for-a-penetration-test **Minimise risk, reduce surprises, and maximise outcomes with expert guidance and preparation for enterprise-level penetration tests. We provide [Penetration Test Preparation Services](/services) to [Sydney, Brisbane and Sunshine Coast](/contact).** ##### Why Preparation Matters A penetration test (pen test) isn’t just a technical check. It’s an evaluation of your website’s security posture, operational maturity, and risk exposure. Without preparation, organisations risk: - False positives or misreported vulnerabilities - Downtime or broken functionality during testing - Delays in remediation due to unorganised environments - Stress and confusion across internal teams Preparation ensures your pen test is efficient, accurate, and actionable — and that your organisation gets the maximum value from it. ##### Common Challenges for Enterprises - Complex websites with multiple integrations and third-party services - Legacy code or outdated plugins that might cause false alerts - Teams unsure which environments or URLs to include in scope - Misalignment between security teams, developers, and management - Difficulty interpreting findings and prioritising fixes > “Our first pen test was chaotic. UnDigital helped us streamline the process, and the results were clear and actionable.” – IT Director, AAP ##### UnDigital’s Approach to Pen Test Preparation We help organisations prepare, optimise, and align for penetration testing without giving away the solutions or interfering with the test itself. Our approach ensures: - Security teams focus on what matters - Developers aren’t scrambling during testing - Your organisation demonstrates governance and control - Findings are meaningful, actionable, and remediable ##### Pen Test Preparation Services **1. Environment Assessment** - Identify all production, staging, and test environments - Map third-party integrations and APIs - Highlight legacy or high-risk components **2. Scope Definition** - Determine what’s in scope and out of scope - Document entry points, login requirements, and critical assets - Ensure testing aligns with compliance requirements **3. Internal Readiness Review** - Review current patching and update status - Identify potential blockers or vulnerabilities that could skew results - Confirm monitoring and backup systems are in place **4. Risk Management & Governance** - Coordinate with internal stakeholders (IT, Security, DevOps) - Document roles and responsibilities during the pen test - Ensure incident escalation procedures are ready **5. Post-Test Planning** - Plan how to prioritise findings - Establish remediation workflows - Align pen test results with governance and compliance reporting ##### Why Enterprises Choose Us Most agencies leave clients to fend for themselves before a pen test. This leads to: - Confusion - Ineffective test results - Increased operational risk UnDigital positions you to get the most value from the test: - Clear, structured preparation - Reduced surprises and downtime - Immediate actionable insights - Confidence that risk is understood and controlled ##### Who This Page Is For Our guidance is for: - [Government departments and agencies](/specialisations) - [Enterprise websites with sensitive data](/specialisations) - Organisations preparing for compliance audits or security certifications - Teams new to penetration testing or those looking to optimise the process If you’re researching “how to prepare for a pen test,” you’re already taking the right step. ##### FAQs **Q: Do we need to tell our internal team everything before a pen test?** A: Only enough to ensure smooth operation and accurate results. UnDigital helps you balance transparency with security. **Q: Will preparation interfere with the test?** A: No. Our goal is to reduce false positives and prevent operational impact, not to pre-empt the test. **Q: How long does preparation take?** A: Typically 1–2 weeks for a standard enterprise website, but it depends on size and complexity. **Q: Is preparation mandatory?** A: No, but it maximises efficiency, reduces risk, and ensures the results are actionable. A penetration test is an investment — don’t let lack of preparation undermine it. --- ### Silverstripe Hosting in Australia: What It Actually Requires URL: https://undigital.com.au/services/silverstripe-hosting-australia-requirements **This page explains what Silverstripe CMS actually requires from a hosting environment, why most generic Australian web hosts cannot run it correctly, and how to tell whether your current arrangement is hosting the platform or merely storing it.** Silverstripe is the CMS of choice for a large share of Australian and New Zealand government and enterprise websites. It is also the platform most often placed on hosting that was never designed for it, usually because the site was quoted as "just a PHP site" by someone who had never deployed one. The result is a site that runs, more or less, until the day it needs a build, a flush, a patch or a traffic spike. #### Why Silverstripe Is Not a Drop-In on Generic Shared Hosting A WordPress site can be dragged onto almost any cPanel account and it will work. Silverstripe cannot, and the reasons are structural rather than incidental. - The application is assembled by Composer at deploy time, not shipped as a folder of files. There is no supported way to install or update it through FTP. - Since Silverstripe 4, the web root is the *public/* directory, not the project root. Hosts that hard-code the document root to *public_html* and refuse to change it will expose *vendor/*, *.env* and your YAML configuration to the internet. - Schema changes are applied by a build task (*dev/build*) that must run with the same PHP binary, environment variables and file permissions as the web process. - A class and configuration manifest is compiled into a cache directory. If that directory is not writable by both the deploy user and the web user, the site fails after deployment rather than during it. - Several standard modules depend on a background worker process or cron entry. Shared hosting often permits neither. None of this is exotic. It is simply a modern PHP application, and it needs an environment built for one. #### The Server Requirements Silverstripe Actually Has ##### PHP version, and why it forces the upgrade conversation Each major line of Silverstripe raises the supported PHP floor, and the platform does not run on unsupported PHP for long. Broadly: | Silverstripe line | Typical PHP support | Practical position today | | --- | --- | --- | | Silverstripe 4 | PHP 7.x, with PHP 8.0 and 8.1 in later 4.x patches | End of life. No further security patches. | | Silverstripe 5 | PHP 8.1 and above | Widely deployed and actively patched. | | Silverstripe 6 | Current supported PHP 8.3 and above | The target for new builds and planned upgrades. | Always confirm the exact constraint against the release notes for the specific minor line you are on. The point for a hosting decision is that the PHP version is not a preference. It is a dependency, and a host that cannot give you a specific patch version of PHP per site, on both the web SAPI and the CLI, will eventually block your [upgrade path from Silverstripe 4 to 5](/services/upgrading-from-silverstripe-4-to-silverstripe-5?stage=Stage) or your move on to 6. A frequent and maddening failure is a version mismatch between the web PHP and the CLI PHP. The site runs on 8.1 and the cron user runs 8.0, so scheduled tasks and queued jobs die silently while the front end looks perfectly healthy. ##### Extensions, limits and directories - Required extensions: *intl*, *mbstring*, *dom*, *xml*, *simplexml*, *tokenizer*, *ctype*, *fileinfo*, *iconv*, *curl*, *zip*, *session*, *pdo* with the relevant database driver, and *gd* or *imagick* for image manipulation. - *memory_limit* of at least 512M for Composer operations and *dev/build*. The default 128M on shared hosting will not complete a build on a site with many DataObjects. - OPcache enabled, with a cache reset built into the deployment step. Without it, a release can serve a mix of old and new class files. - A writable temporary cache directory outside the web root, owned consistently. Running *dev/build* as root and then serving as *www-data* is one of the most common causes of a post-deploy white screen. ##### Web server configuration Apache can use the shipped *.htaccess* in *public/*, provided *AllowOverride* and *mod_rewrite* are enabled. Nginx has no equivalent, so the rules must be written by hand: route everything not matching a real file to *index.php*, and explicitly deny requests for */vendor*, */.env*, */assets/.protected* and the cache directory. Nginx configurations copied from a WordPress template are a standing security problem on Silverstripe sites, because they assume nothing sensitive sits beside the index file. #### Deployment: Composer, Build Steps and dev/build A correct Silverstripe deployment is a sequence, not a file copy: - *composer install --no-dev --optimize-autoloader* against the committed lock file, so the build is reproducible. - The Composer vendor plugin exposes module assets into *public/_resources*. If this step is skipped, the CMS loads with no styling and no JavaScript. - Front end asset compilation, if the theme uses a build toolchain. - *sake dev/build* from the CLI, with the environment loaded, to apply schema changes. - A manifest flush and OPcache reset before the release is switched live. Two details matter more than they look. First, *dev/build* is additive: it creates tables and columns but never drops them, so schema drift accumulates quietly across years of development. Second, *?flush=1* on a live site under load is dangerous, because every concurrent request attempts to rebuild the manifest at once. On a properly configured environment the cache is warmed on the new release directory before traffic is switched to it, which is why atomic symlink deployments and [a real CI/CD pipeline](/press/getting-started-with-cicd-a-beginners-guide-to-continuous-integration-and-continuous-deployment?stage=Stage) are not optional extras for this platform. #### Assets, File Storage and the Public Directory Silverstripe 4 and later split file storage in two. Published files live under *public/assets* and are served directly by the web server. Draft, restricted and unpublished files live under *assets/.protected* with hashed paths and are streamed through PHP after a permission check. This breaks in predictable ways. A CDN or nginx rule that serves */assets* straight from disk will either bypass the permission check or return 404s for draft files that editors can see in the CMS. A load balanced pair of web servers with local disks will drift apart within a day of editors uploading files, so assets need shared storage: NFS or EFS, or an S3 backed Flysystem adapter with the CDN in front of it. Migrating an existing site into S3 storage is a task in its own right, not a configuration toggle, because the legacy file paths must be rewritten as they move. #### Database Behaviour Under Load Silverstripe runs on MySQL 5.7 or later and MariaDB, with PostgreSQL available through a community maintained module that does not have full feature parity. For anything with a compliance obligation, MySQL 8 or a supported MariaDB release is the safer choice. The behaviour that surprises people is the ORM under content weight: - **Versioned tables grow without bound.** Every publish writes to *_Versions*, and on a site using Elemental content blocks each page publish can write dozens of version rows across multiple block tables. Sites that have been edited daily for five years routinely carry version tables an order of magnitude larger than the live tables. - **Lazy loading produces N+1 queries.** A template loop that touches a relation on each item issues a query per iteration. Recent Silverstripe 5 releases added explicit eager loading on DataLists, which resolves it, but only if someone reads the slow query log and applies it. - **Partial match filters are full table scans.** A search page built on *PartialMatchFilter* generates *LIKE '%term%'*, which no index will help. At scale that needs a real search index rather than a bigger database server. - **Custom indexes must be declared.** Silverstripe indexes relation fields, but filters on your own fields need *private static $indexes* in the model and a rebuild to take effect. Tuning the InnoDB buffer pool to hold the working set, enabling the slow query log with a low threshold, and reviewing it monthly will find more performance than any amount of extra CPU. #### Background Jobs, Scheduled Tasks and Search Most enterprise Silverstripe sites run the queued jobs module. It requires either a cron entry executing the queue processor every minute, or a supervisor managed long running worker. If neither exists, scheduled publishing, bulk imports, sitemap regeneration, notification emails and static cache rebuilds all queue up and never run, with no visible error on the front end. Monitoring should alert on queue depth and on the age of the oldest unprocessed job, not just on whether the site returns a 200. Full text search through the fulltextsearch module typically means running Solr, which is a JVM service with its own memory profile, its own patching schedule and its own reindexing tasks. No shared host will run it for you. #### Caching Layers That Actually Work on Silverstripe - **Partial caching** in templates, with cache keys that include every piece of state the block depends on, including member status. Getting a key wrong shows one visitor another visitor's content. - **Static publishing** via the static publish queue module, which writes rendered HTML on publish. Effective for content sites, and dependent on the queue worker described above. - **HTTP cache control.** Silverstripe's cache control middleware deliberately sends no-cache headers for authenticated sessions and CMS requests. Any edge configuration must respect that and bypass the cache when a session cookie is present. - **Edge caching and WAF.** Putting [Cloudflare in front of the origin](/services/benefits-of-cloudflare-for-enterprise-websites?stage=Stage) absorbs traffic spikes and bot load, but the cache rules have to be written against Silverstripe's actual behaviour, including form submissions carrying a SecurityID token that must never be cached. #### Security Patching and the Silverstripe Release Process Silverstripe publishes security advisories with their own identifiers and, where applicable, CVE numbers, and pre-notifies partners under embargo before public disclosure. Patches are issued only for supported minor lines. This has a consequence that catches many organisations: staying secure is not just applying patches, it is staying current enough on minor releases to be eligible for them. Because the CMS is installed as a recipe, a patch typically updates a set of modules together. That makes a staging environment mandatory, along with regression checks over the CMS interface, forms, file handling and any custom modules, before the change reaches production. Applying a Silverstripe security release blind on a Friday afternoon is how a working site becomes an incident. This is ongoing [Silverstripe website management](/managed-hosting/silverstripe-website-management?stage=Stage) work, and it is exactly the work that pure infrastructure providers exclude from scope. #### Hosting Models Compared | Capability | Shared cPanel hosting | Self-managed VPS or cloud | Managed Silverstripe hosting with SLA | | --- | --- | --- | --- | | SSH and Composer access | Rarely, and often on the wrong PHP | Yes | Yes, with a defined pipeline | | Per-site PHP version control (web and CLI) | Limited, often mismatched | Yours to configure | Managed and version matched | | Web root set to public/ | Frequently refused | Yours to configure | Standard | | Queued jobs worker and cron | Usually not permitted | Yours to build and monitor | Supervised and alerted on | | Protected assets served correctly | Commonly misconfigured | Yours to verify | Verified as part of setup | | Silverstripe security patches applied | No | No | Yes, tested on staging first | | Application code fixed when it breaks | No | No | Yes | | Who is accountable at 2am | The server only | You | One vendor, under SLA | #### What Breaks When Hosting and Development Are Separate Vendors The most expensive Silverstripe failures are rarely technical mysteries. They are boundary disputes. The hosting provider confirms the server is up, CPU is normal and disk is fine, which is true. The development agency says nothing has been deployed for six weeks, which is also true. Meanwhile the queue worker stopped after a kernel update, no one owns the queue worker, and the site has not published a page in nine days. Other common versions of the same problem: a PHP minor upgrade rolled out by the host breaks a module and nobody had a staging environment to catch it; a security release lands and the host says patching is the developer's job while the developer says they are no longer on retainer; disk fills with version table growth and log files and the fix requires a database change nobody is authorised to make. Every one of these needs someone who can read a stack trace and change infrastructure in the same afternoon. That is why the useful contract is one that covers both layers with a single response time, which is what a properly written [website support SLA for enterprise and government](/services/website-support-slas-for-enterprise-and-government?stage=Stage) is for. #### Frequently Asked Questions ##### Can Silverstripe run on standard shared hosting in Australia? Technically yes, in the sense that PHP will execute. In practice most shared hosting cannot set the web root to the *public/* directory, cannot give you SSH and Composer, cannot run a queued jobs worker, and cannot guarantee that the CLI PHP version matches the web PHP version. Sites on shared hosting usually work until the first upgrade or the first traffic spike, then need to be moved. ##### What PHP version does Silverstripe need? It depends on the major line. Silverstripe 4 supported PHP 7.x and, in later patch releases, PHP 8.0 and 8.1, but it is now end of life. Silverstripe 5 requires PHP 8.1 or later and Silverstripe 6 requires a current PHP release. Confirm the exact constraint in the release notes for your specific minor version before planning a server upgrade. ##### Does Silverstripe hosting need to be in Australia? For commercial sites the main argument is latency to Australian visitors and to any locally hosted integrations. For government agencies and organisations handling personal information, data residency policies and procurement requirements often make onshore hosting non-negotiable, which means an Australian region for both the application servers and the database, including backups. ##### Why does my Silverstripe site break after a deployment? The three usual causes are a missing *dev/build*, a manifest cache directory with the wrong ownership after the build was run as a different user, and Composer's vendor expose step not running, which leaves the CMS without its CSS and JavaScript. All three are eliminated by a scripted deployment pipeline that performs the steps in a fixed order and warms the cache before switching traffic. ##### How often should Silverstripe security patches be applied? Security releases should be assessed as soon as they are published and applied on a timeframe matched to their severity, with critical advisories treated as an out-of-cycle change rather than waiting for the next maintenance window. Patches are only issued for supported minor lines, so an ongoing programme of minor upgrades is part of staying patchable at all. ##### Can you take over hosting for a Silverstripe site built by another agency? Yes, and it is a routine engagement. It starts with an audit of the codebase, the Composer lock file, the current server configuration, the asset store and the database, followed by a staged migration with DNS cut over last. Sites are commonly found to be several minor versions behind, running unsupported PHP, or missing a queue worker entirely. #### Silverstripe Hosting and Management with UnDigital UnDigital is an official Silverstripe Partner and has been building and running Silverstripe sites for Australian government and enterprise organisations for over a decade, including [pioneering the platform's use within NSW Government](/press/undigital-pioneers-the-use-of-silverstripe-cms-within-nsw-government?stage=Stage). We host on dedicated Australian infrastructure with 24/7 monitoring, 6-hourly backups, WAF and DDoS protection, and uptime SLAs from 99.9 to 99.99 per cent. The distinction that matters is that we do not stop at the server. Composer deployments, *dev/build* execution, queue worker supervision, asset store configuration, slow query review, security release testing and minor version upgrades are all inside scope, because they are what running this platform actually involves. If you already have AWS or Azure infrastructure you want to keep, we can take the management layer only. Everything begins with an infrastructure audit and is scoped individually. See [Silverstripe hosting](/managed-hosting/silverstripe-hosting?stage=Stage) for the hosting side, or [our Silverstripe hosting and maintenance partner agency page](/silverstripe-hosting-and-maintenance-partner-agency?stage=Stage) if you are an agency looking to hand fulfilment to a specialist. --- ### Upgrading from Silverstripe 4 to Silverstripe 5 URL: https://undigital.com.au/services/upgrading-from-silverstripe-4-to-silverstripe-5 **Reduce security risk, improve long-term stability, and future-proof your website with a structured Silverstripe upgrade approach. We provide [Silverstripe 4 to Silverstripe 5 Upgrade Services](/services) to [Sydney, Brisbane and Sunshine Coast](/contact).** ##### Why Organisations Are Still on [Silverstripe 4](/technology) Silverstripe 4 has served enterprise and government websites well for years. Many organisations stayed on it because: - The website is stable and “still works” - Custom functionality makes upgrades feel risky - Internal teams are resource-constrained - The cost of change feels hard to justify Unfortunately, stability today does not equal safety tomorrow. ##### The Real Risks of Staying on Silverstripe 4 As platforms mature, the risk isn’t sudden failure — it’s gradual exposure. Organisations remaining on Silverstripe 4 face: - Increasing security vulnerabilities - Reduced compatibility with modern hosting and infrastructure - Declining third-party module support - Difficulty passing security reviews or penetration tests - Higher long-term maintenance and fix costs At an enterprise level, this becomes a governance and risk issue, not just a technical one. ##### What [Silverstripe 5](/technology) Changes (At a High Level) Silverstripe 5 represents a modernisation of the platform — not a cosmetic update. Key improvements include: - Improved security foundations - Modernised dependencies and architecture - Better alignment with current PHP ecosystems - Stronger long-term support trajectory For organisations planning future enhancements, Silverstripe 5 is the baseline moving forward. ##### Why Silverstripe 4 → 5 Upgrades Are Not Simple This upgrade is rarely “click and go”. [Enterprise websites](/specialisations) often include: - Custom modules and extensions - Legacy integrations - Role-based workflows - Complex content structures Without careful planning, upgrades can introduce: - Broken functionality - Data integrity issues - Unexpected downtime - Increased remediation cost This is why many organisations delay — and why upgrades should be treated as controlled transition projects, not maintenance tasks. ##### UnDigital’s Upgrade Philosophy We don’t treat Silverstripe upgrades as version jumps. We treat them as: - Risk reduction exercises - Stability improvements - Opportunities to reduce technical debt Our approach prioritises: - Continuity - Security - Predictable outcomes - Minimal operational disruption ##### Who Should Be Considering This Upgrade Now - Government and regulated organisations - Enterprise websites subject to security reviews - Sites relying on long-term vendor support - Organisations planning future feature development - Teams already experiencing maintenance friction If you’re researching Silverstripe 4 to 5 upgrades, you’re likely already at this decision point. ##### Common Questions We Hear **Is Silverstripe 4 still safe?** It may function, but its risk profile increases over time as support and compatibility decline. **Can we skip straight to Silverstripe 6?** That depends on architecture, customisation, and organisational readiness. This decision should be assessed, not guessed. **Is an upgrade the same as a rebuild?** No — but poorly handled upgrades often turn into one. Proper planning avoids that. ##### Next Step If your organisation relies on Silverstripe 4, upgrading is about control, not panic. We can help you: - Assess risk - Plan the upgrade - Execute safely - Support the platform long-term --- ### Upgrading from Silverstripe 5 to Silverstripe 6 URL: https://undigital.com.au/services/upgrading-from-silverstripe-5-to-silverstripe-6 **Understand the implications of upgrading from [Silverstripe 5](/technology) to 6 and make the decision with confidence, not urgency. We provide [Silverstripe 5 to Silverstripe 6 Upgrade Services](/services) to [Sydney, Brisbane and Sunshine Coast](/contact).** ##### Why [Silverstripe 6](/technology) Is on People’s Radar Silverstripe 6 introduces another step forward in platform evolution. For organisations already on Silverstripe 5, the conversation is no longer if upgrades matter — it’s when and why. Enterprise teams are asking: - Do we need to upgrade now? - What are the risks of waiting? - Is this a maintenance task or a project? These are the right questions. ##### What Silverstripe 6 Represents (Without the Hype) Silverstripe 6 is not about flashy features. It’s about: - Future compatibility - Improved maintainability - Alignment with modern development standards - Long-term platform viability For organisations planning multi-year digital roadmaps, Silverstripe 6 matters. ##### The Risk of Rushing a Silverstripe 5 → 6 Upgrade Unlike earlier upgrades, this step often affects: - Custom code assumptions - Module compatibility - Hosting and infrastructure alignment Rushing introduces: - Unplanned rework - Extended downtime - Increased cost - Stakeholder frustration Enterprise teams benefit from measured, well-timed upgrades, not reactive ones. ##### When Upgrading to Silverstripe 6 Makes Sense Upgrading becomes strategically sound when: - You’re planning significant feature enhancements - Long-term support and security are priorities - You want to reduce future technical debt - Your organisation values platform longevity In some cases, staying on Silverstripe 5 temporarily is a valid decision — if risk is understood and managed. ##### How UnDigital Helps Organisations Decide We don’t push upgrades for the sake of it. We help organisations: - Understand platform risk - Evaluate readiness - Align upgrades with business timelines - Avoid unnecessary disruption Our role is advisory first, execution second. ##### Who This Page Is For - [Government departments](/specialisations) on Silverstripe 5 - [Enterprise organisations](/specialisations) planning multi-year roadmaps - Digital teams under pressure to “future-proof” - Stakeholders balancing cost, risk, and timing If you’re researching Silverstripe 6, you’re already thinking long-term. ##### Common Questions **Is Silverstripe 6 required immediately?** Not always. The decision depends on risk tolerance, support needs, and future plans. **Is Silverstripe 6 more secure?** Yes — but only when implemented and maintained correctly. **Can we combine an upgrade with other improvements?** Often yes, but this should be planned carefully to avoid scope creep. ##### Next Step Silverstripe upgrades aren’t about chasing versions. They’re about protecting your investment. We help organisations make upgrade decisions with clarity, not pressure. --- ### Urgent Website Support: What to Do in the First Hour URL: https://undigital.com.au/services/urgent-website-support-first-hour **A practical first-hour runbook for anyone whose website is down, degraded or defaced right now, covering triage, diagnosis, evidence preservation and restoring service safely, written for IT managers, marketing leads and agency owners who need urgent website support.** Most website outages are made worse in the first thirty minutes. Someone restores a backup over the top of a compromised server and destroys the evidence. Someone flushes the CDN cache while the origin is still returning errors and pushes the failure to every edge location. Someone reboots the box, the symptom disappears, and it returns four hours later during peak traffic because nobody found the cause. The sequence below is the order of operations we follow on incidents. Work through it rather than jumping to the fix you assume is required. #### Before You Do Anything: Establish What Is Actually Broken "The website is down" is a report, not a diagnosis. Before touching anything, answer four questions and write the answers down with timestamps: - **Is it down for everyone, or for you?** Test from a mobile connection off the corporate network, and from an external checker. A corporate DNS resolver or a firewall rule can produce a convincing but entirely local outage. - **What is the actual HTTP response?** Run curl -sSI https://yourdomain.com.au. A 500 is an application error. A 502 or 504 means something in front of the application cannot reach it or is waiting on it. A 403 is often a WAF rule. A connection timeout with no status code at all is a network, DNS or firewall problem, not an application one. - **What changed?** Deployments, plugin or module updates, DNS edits, certificate renewals, firewall changes, a new WAF rule, a database migration, a password rotation, an expired credit card on a cloud account. Most incidents follow a change within the previous 48 hours. - **Is anything else affected?** Email, the CRM, the payment gateway, a second site on the same server. Shared symptoms point to shared infrastructure. #### Triage in the First Ten Minutes - Capture the exact error the public sees, with a screenshot and the full response headers. This is your baseline and your evidence. - Check whether the origin server is reachable independently of the CDN, by requesting it on its IP address with a Host header, or via a staging hostname that bypasses the proxy. - Check certificate validity and expiry: openssl s_client -connect yourdomain.com.au:443 -servername yourdomain.com.au. - Check DNS resolution from an authoritative nameserver and from a public resolver: dig yourdomain.com.au A +trace and dig @1.1.1.1 yourdomain.com.au. - Log in to the server and check disk, inodes, load and memory before you look at application code. - Tail the web server and application error logs and note the first occurrence of the error, not the most recent one. The first occurrence tells you when the incident actually began. - Decide the severity, tell stakeholders what you know and what you do not, and give them a time for the next update rather than a time for the fix. #### Symptom to Cause: Reading the Failure Correctly | What the visitor sees | Most common causes | First check | | --- | --- | --- | | Connection timed out, no response | DNS change, security group or firewall rule, instance stopped, origin IP changed | dig +trace, then ping and port 443 from outside the network | | 502 Bad Gateway | PHP-FPM or Node process dead, socket permissions, application crash on boot | Service status and the web server error log | | 504 Gateway Timeout | Slow query, external API hanging, exhausted worker pool, runaway cron | Database process list and slow query log | | 500 Internal Server Error | Fatal PHP error after an update, missing environment variable, failed migration | Application error log, most recent deployment | | 403 Forbidden or a challenge page | WAF rule, rate limiting, IP reputation, bot management | CDN and WAF event log for the visitor's IP | | Browser certificate warning | Expired certificate, failed ACME renewal, missing intermediate, SNI mismatch | openssl s_client output and the renewal timer or cron | | Site loads but is defaced or redirects offsite | Compromised admin account, vulnerable plugin or module, injected template or database content | File modification times and the users table, then stop and preserve evidence | #### DNS, TLS and CDN Failures That Look Like Application Failures ##### DNS A registrar auto-renewal failure, a nameserver change made by a third party, or a DNSSEC mismatch will take a site offline completely while the server sits there healthy. Check the domain expiry date, the delegated nameservers, and whether the A or CNAME records still point at the current origin or CDN. If a record was changed, remember the previous TTL governs how long the old value lingers in resolvers. ##### TLS Certificate expiry remains one of the most frequent avoidable outages, usually because an automated renewal has been failing silently for weeks. A renewal will fail if the HTTP-01 challenge path is blocked by a redirect rule, if a WAF challenges the certificate authority's request, or if the DNS API credentials used for DNS-01 have been rotated. Check the renewal log, not just the expiry date. If you are behind Cloudflare, a 526 means the edge does not trust the origin certificate, which is a different problem from a public expiry. ##### CDN and WAF Cloudflare's 5xx family is diagnostic: 521 means the origin refused the connection, 522 means it did not answer within the timeout, 523 means the origin is unreachable at the network level, and 525 or 526 are TLS handshake failures between edge and origin. These point at the origin or the network path, not at your code. Equally, a new firewall rule or a managed ruleset update can start blocking legitimate traffic, form submissions or an integration's API calls. The [event log at the edge](/services/benefits-of-cloudflare-for-enterprise-websites) will show a rule ID against every blocked request, which is the fastest way to confirm or eliminate the WAF. #### Server-Level Diagnosis Work from the bottom of the stack upwards. In rough order of frequency: - **Disk and inodes.** df -h and df -i. A full /var caused by log growth, an unrotated debug log, session files or database binary logs will produce write errors that surface as 500s. Inode exhaustion presents as a full disk that reports free space. - **Memory and the OOM killer.** free -m and dmesg -T | grep -i oom. If the kernel killed MySQL or a PHP worker, the application error is a symptom, not the cause. - **Process pools.** For PHP-FPM, compare active children against pm.max_children in the pool config. Requests queue silently once the pool is saturated, which the user experiences as a 504. - **Database connections.** SHOW PROCESSLIST and SHOW STATUS LIKE 'Threads_connected' against max_connections. One unindexed query behind a newly published page can hold enough connections to lock out the whole site. - **Scheduled tasks.** An overlapping cron or queue worker, especially an import or reindex, will consume every available resource on a schedule. Recurring outages at the same minute past the hour are almost always cron. #### Signs of Compromise, and Why You Should Not Restore Yet Stop and treat the incident as a security event, not an outage, if you see any of the following: PHP files inside an uploads directory, files modified at a time nobody deployed, an administrator account you do not recognise, unexpected outbound connections, obfuscated code appended to index.php or a theme or template file, injected spam content in database rows, new cron entries, or a sudden spike in outbound mail. Restoring a backup at this point is the wrong instinct. If the entry point was a vulnerable component or a stolen credential, the restored site is compromised again within hours, and you have overwritten the evidence needed to work out how they got in. You also cannot tell your board, your insurer or your customers what was accessed. Where personal information may have been exposed, that determination has legal consequences under the Notifiable Data Breaches scheme, and it is difficult to make once the disk is gone. ##### Preserve Evidence Before You Remediate - Take a snapshot or image of the volume before changing anything on it. - Copy web server access and error logs off the server immediately, before rotation deletes the window you need. - Export CDN and WAF logs, which often retain the request that succeeded when the origin logs do not. - Record a timeline in a single timezone, with the first known good and first known bad timestamps. - Rotate credentials off the compromised host: CMS administrators, database users, SSH keys, API tokens, deployment secrets and any shared passwords. - Isolate rather than delete. Take the site to a maintenance page or restrict it to known IP addresses while you work. #### Restoring Service: Roll Back, Restore or Fix Forward Once you know the cause, choose deliberately. Rolling back the last deployment is the fastest option when the incident began at a release and the database schema has not changed. Restoring from backup is appropriate for data loss or content damage, and its cost is every change made since the snapshot, which is why the recovery point matters as much as the recovery time. Fixing forward is right when the fault is a single configuration value, a certificate, a firewall rule or a query, and the fix is understood and small. Whichever you choose, verify against the origin before clearing the CDN cache, confirm forms, logins, checkout and any integration that touches the fault, and keep monitoring in place for at least an hour afterwards. Silent failure of a background process is common after a restore. #### When Your Vendor Is Not Answering The most common reason an outage runs for days is not technical. It is that the hosting provider will not touch the application and the web agency has no access to the infrastructure, so each refers you to the other. If you are in that position, get three things in front of whoever helps you next: registrar and DNS access, server or cloud console access, and the code repository. With those, a competent team can act. Without them, everyone is guessing. If your contract carries response commitments that were not met, record the times you notified the vendor and the times they responded, because that record is what makes the conversation about a [breach of your service level agreement](/services/website-sla-breach-what-to-do-next) a factual one. Where an incident is live and unowned, [emergency break/fix engagement](/services/break-fix-and-emergency-website-support) exists precisely to put someone on it now, independent of whoever built the site. #### Incident Severity and Expected Response Compared | Severity | Definition | Typical examples | What a mature response looks like | | --- | --- | --- | --- | | P1 Critical | Site or transactional function unavailable to all users, or an active security incident | Total outage, defacement, data exposure, checkout failing | Immediate acknowledgement, engineer engaged, updates on a fixed interval until service is restored | | P2 High | Major degradation or a key function broken for a subset of users | Forms not submitting, search failing, severe slowness, one template erroring | Same business day engagement, workaround deployed if a full fix will take longer | | P3 Medium | Non-critical fault with a workaround | Layout defect, a report not generating, a minor integration lag | Scheduled into the next maintenance window with an agreed date | | P4 Low | Cosmetic or requested change | Copy edits, small styling issues, enhancement requests | Batched into planned work | Severity should be defined in writing before an incident, along with who can declare a P1, what hours the commitment covers, and how updates are communicated. Arguing about priority during an outage costs time nobody has. #### After the Incident: Root Cause and Preventing a Repeat Within a few days of service being restored, produce a short written record: what happened, when it was detected, how it was detected, what the cause was, what was done, and what will change. Detection is the part most organisations skip, and it is usually the biggest opportunity. If a customer told you before your monitoring did, [external uptime and transaction monitoring](/website-uptime-monitoring) is the cheapest improvement available. The other durable fixes are unglamorous: patch the components that were out of date, add alerting on disk, memory and certificate expiry, verify that backups restore rather than merely run, remove administrator accounts nobody uses, enable multi-factor authentication, and put a repeatable deployment process in place so rollback is a command rather than an improvisation. Ongoing [security monitoring and patch management](/services/website-security-management-and-monitoring) exists to make the next incident smaller, or to make sure there is no next incident of the same kind. #### Frequently Asked Questions ##### What should I do first when my website goes down? Confirm the outage from outside your own network, then capture the exact HTTP response with a tool such as curl so you know whether you are dealing with a timeout, a 5xx from the server, or a block from a firewall. Note what changed in the previous 48 hours. Do not restart services or restore backups until you have recorded the error and the time it started. ##### Can I get emergency website support in Australia if I am not an existing client? Yes. Emergency break/fix support is offered as a standalone engagement for organisations whose current provider is unavailable or unable to resolve the issue. What is needed to start is access: DNS and registrar, the server or cloud console, and the code repository. Many organisations move to an ongoing support agreement afterwards, but that is not a condition of getting help during the incident. ##### Should I restore a backup if my site has been hacked? Not immediately. Restoring overwrites the evidence needed to identify how the attacker gained access, and if the entry point is still open the site will be compromised again quickly. Take a snapshot and copy the logs off the server first, rotate every credential, identify and close the vulnerability, then restore to a clean environment. ##### What counts as a breach of a website SLA? A breach occurs when the provider fails to meet a commitment written into the agreement, most often the response or resolution time for a given severity, or the monthly uptime percentage. To rely on it you need dated evidence: when you notified them, through the agreed channel, and when they actually responded. Independent uptime monitoring is far more persuasive than the provider's own dashboard. ##### Why does my host say the server is fine when my site is clearly broken? Because both statements can be true. Hosting providers typically monitor the machine, not the application, so a healthy server running a crashed PHP process, an expired certificate or a fatal error after a plugin update is still "fine" by their measure. Resolving it requires someone with both infrastructure access and the ability to work on the application code. ##### How quickly should a critical website incident be acknowledged? For a genuine P1 affecting all users or involving a security event, acknowledgement should be immediate and an engineer should be actively working within the response window defined in your agreement, including outside business hours if your agreement covers them. Just as important is the update cadence: a fixed interval for status updates until service is restored, even when the update is that work is continuing. #### Emergency Support and Ongoing SLAs from UnDigital UnDigital runs infrastructure and the development capability to act on it, which is why our incidents do not stall at the boundary between the host and the site. We take on live incidents through [break/fix emergency support](/services/break-fix-and-emergency-website-support), and we hold ongoing responsibility for enterprise and government websites under [defined support SLAs](/services/website-support-slas-for-enterprise-and-government) covering monitoring, patching, backups, security and response times. If your website is critical to sales or lead generation, the aim is to make outages rare, short and explainable. If you are in an incident now, call. If you are reading this after one, the conversation worth having is about what happens the next time. --- ### Website Availability Monitoring: Synthetic, RUM and Alerting URL: https://undigital.com.au/services/website-availability-monitoring-synthetic-rum-alerting **This page explains how website availability monitoring actually works: how uptime is measured and mis-measured, the difference between synthetic checks, real user monitoring, log-based detection and heartbeats, and how to design alerting and escalation so an outage reaches a human who can fix it. It is written for IT managers, digital leads and agency owners responsible for a website that generates revenue or leads.** #### Availability is a measurement decision before it is a technical one Most organisations discover their monitoring is wrong during an incident, not before one. The site is down, customers are calling, and the dashboard is a wall of green. The tool did exactly what it was configured to do. It requested the homepage over HTTP, received a 200 response, and recorded the site as available. The fact that the checkout threw a 500, the search index was unreachable, or the CMS had locked every editor out was never part of the measurement. So the first question is not which tool to buy. It is: what does "available" mean for this website? For a government information site, available might mean the homepage and a set of key service pages render with status 200 and complete content. For an ecommerce site, availability without a working add-to-cart and payment gateway is meaningless. For a lead generation site, a form that silently fails to submit is a total outage of the only function that matters, and every uptime tool on the market will call it 100% available. Write the definition down before you configure anything. A useful definition names the specific transactions that must work, the response time above which the page is considered failed rather than slow, and the locations users actually come from. Everything else in monitoring follows from that. #### How uptime percentages are calculated, and how they are gamed Uptime is usually expressed as the percentage of measured intervals in a period where the target responded successfully. The numbers sound close together and are not. | Target | Downtime per month | Downtime per year | Realistic for | | --- | --- | --- | --- | | 99.0% | 7h 18m | 3d 15h | Single server, manual recovery | | 99.5% | 3h 39m | 1d 19h | Shared or budget hosting | | 99.9% | 43m | 8h 45m | Managed single-region, monitored | | 99.95% | 21m | 4h 22m | Redundant application tier | | 99.99% | 4m 22s | 52m | Multi-AZ, automated failover | The percentage only means something once you know what was measured and what was excluded. Common ways a reported figure flatters reality: - **Infrastructure uptime, not website uptime.** The virtual machine responded to ICMP the whole time. PHP-FPM was refusing connections for forty minutes. The host reports 100%. - **Five-minute check intervals.** A four-minute outage between checks did not happen as far as the record is concerned. At one-minute intervals it does. - **Excluded maintenance windows.** Planned downtime is often carved out of the calculation entirely, which is defensible if the window is agreed in advance and unreasonable if it is declared retrospectively. - **Homepage-only checks.** The one page most likely to be served from cache or a CDN edge, and therefore the last thing to fail. - **Status code only.** A WordPress white screen of death, a Silverstripe error template or a "we'll be back soon" page can all return 200. Insist that the SLA defines the check target, the interval, the number of consecutive failures required to declare an outage, and how the clock starts. A target without those four details is not measurable, which is usually the point. #### Synthetic, real user, log-based and heartbeat monitoring These four approaches detect different failures. Serious availability monitoring uses at least three of them, because each one is blind to something the others catch. | Method | How it works | Detects | Blind to | Typical detection lag | | --- | --- | --- | --- | --- | | Synthetic checks | Scheduled requests from external agents, HTTP or headless browser | Total outages, TLS failures, DNS failures, slow responses, content changes | Faults on paths not being checked, issues affecting only logged-in users | Interval plus confirmation, typically 1 to 3 minutes | | Real user monitoring (RUM) | JavaScript beacon in the page reporting timings and errors from actual browsers | Regional degradation, browser-specific breakage, JS errors, Core Web Vitals regressions | Complete outages, because a down page loads no beacon | Minutes, and only during traffic | | Log and metric based | Alerting on error rates, response times and queue depth from server or CDN logs | Rising 5xx rates, partial failures, one broken app node behind a load balancer | Anything upstream of your logging, including DNS and network faults | Near real time | | Heartbeat / dead man's switch | A job pings an external endpoint on completion; absence of the ping alerts | Failed cron, stalled queue workers, backups that stopped running | Web-facing availability | Configured grace period | RUM deserves special mention because it is frequently misunderstood as an uptime tool. It is not one. When the site is truly down, RUM goes quiet, and a quiet dashboard looks like a quiet night. RUM's value is in telling you that Perth users are seeing four second page loads while Sydney users are fine, which is a class of failure synthetic checks from a single location will never surface. #### Check frequency, geography and false positive suppression Check frequency sets the floor on how fast you can possibly know. A 60 second interval on critical paths and 5 minutes on secondary paths is a reasonable starting shape. Going below 30 seconds rarely helps, because confirmation logic eats the gain. Run checks from at least three geographically separate locations, including at least one inside Australia and one offshore. Two reasons. First, a single vantage point cannot distinguish "the site is down" from "the route between this agent and your origin is down", and transit incidents are common. Second, if you serve Australian users through a CDN, you want to know when an Australian edge is misbehaving while the origin is perfectly healthy. [Cloudflare and similar edge networks](/services/benefits-of-cloudflare-for-enterprise-websites?stage=Stage) add a layer that can fail independently of your infrastructure, and monitoring the origin alone will not see it. False positives are the real enemy, because an on-call engineer who has been woken three times by a flapping check will start ignoring the fourth. Practical suppression: - Require two or three consecutive failures from two different locations before declaring an outage. - Retry immediately from a second region rather than waiting for the next scheduled interval. - Set realistic timeouts. A 5 second timeout on a page that legitimately takes 4 seconds under load generates noise, not signal. - Exclude monitoring agents from rate limiting and bot protection rules, or your WAF will manufacture outages. - Alert on error rate as a proportion of traffic rather than absolute counts, so a quiet Sunday and a busy Monday behave the same. #### Multi-step journey checks A single GET request tells you the web server is alive. It tells you almost nothing about whether the business function works. Scripted browser checks that walk a real journey are where availability monitoring becomes useful, because they exercise the database, session handling, third party APIs and payment gateways in the same sequence a customer does. Journeys worth scripting, in rough order of value: - **Authenticated login.** Catches session store failures, expired API credentials and SSO or IdP outages that a public page check cannot see. - **Search.** Exercises Elasticsearch, Solr or the database index. Search failing silently and returning zero results is a classic invisible outage. - **Form submission.** Submit a test enquiry through the real form with a tagged identifier, and assert both the confirmation page and, where possible, the record landing in the CRM. - **Add to cart and checkout to payment step.** Stop short of capturing funds, but go far enough to confirm the gateway handshake succeeds. - **CMS admin login.** Editors locked out of the CMS is an outage for the people who pay for the site, even if the public front end is perfect. Scripted journeys need maintenance. A redesign changes a selector, the check breaks, and nobody notices for a month. Treat check scripts as code, version them, and review them whenever the application changes. This is one of the reasons monitoring tends to decay when it is owned by a tool vendor rather than by the team that also maintains the application. #### Certificate, DNS, cron and queue monitoring nobody configures The outages that cause the most damage are usually not server crashes. They are silent expiries and stopped background work. - **TLS certificate expiry.** Alert at 30, 14 and 7 days, and monitor the full chain, not just the leaf. An expired intermediate breaks older clients while modern browsers happily rebuild the path and show green. - **Domain registration expiry.** Rarer, far worse, and entirely preventable with a calendar alert and a second contact on the registrar account. - **DNS resolution and record drift.** Check that the A, AAAA, CNAME and MX records resolve to expected values from multiple resolvers. Also monitor SPF, DKIM and DMARC, because transactional email failing is an availability problem for anything involving password resets or order confirmations. - **Scheduled tasks.** Every cron job that matters should report completion to a heartbeat endpoint. Sitemap generation, index rebuilds, feed imports and, most importantly, backups. - **Queue depth and worker health.** A queue that grows monotonically is an outage in slow motion. Alert on depth and on oldest-message age, not just on worker process count. - **Disk, inode and database connection saturation.** These have a predictable trajectory, so they should be warnings hours before they become incidents. - **Backup restorability.** A backup job that completes is not a backup. Periodic test restores into a scratch environment are the only check that means anything. #### Alert design: thresholds, deduplication and escalation An alert is a request for a human to do something. If nothing needs doing, it should not be an alert. Apply that test ruthlessly and most monitoring noise disappears. ##### Severity tiers Three tiers are usually enough. Critical means the site or a core transaction is unavailable and someone is woken regardless of the hour. High means degraded but functional, actioned within business hours or the next morning. Informational goes to a channel, never to a phone. Certificate expiring in 30 days is informational. Certificate expiring in 48 hours is critical. ##### Deduplication and correlation When an origin server fails, a naive setup fires separate alerts for the homepage check, five journey checks, the error rate threshold and three heartbeats, all within ninety seconds. Alerts should be grouped into a single incident with a single owner. Suppress downstream alerts when an upstream dependency is already known to be failing, and suppress everything inside an agreed maintenance window. ##### Escalation ladders and on-call The escalation ladder is what turns a notification into a response. A workable pattern: notify the primary on-call engineer by push and SMS; if unacknowledged after 5 minutes, call them; after 10 minutes, escalate to the secondary; after 20 minutes, escalate to the technical lead and notify the client contact. Acknowledgement must be an explicit action, not an email being opened. Ladders only work if the roster behind them is real. That means named people, a published rotation, handover between them, and cover for leave and public holidays. A three person in-house team cannot sustain genuine 24/7 on-call without burning out, which is the quiet reason so many organisations have excellent monitoring and terrible response times. If you are assessing your current arrangement, the questions in our guide to [evaluating a managed web services provider](/services/how-to-evaluate-a-managed-web-services-provider?stage=Stage) are a useful place to start. #### What happens between the alert firing and service being restored This is the gap that monitoring products cannot close, and it is where the real cost of an outage sits. Detection might take ninety seconds. Restoration takes as long as it takes someone with credentials, context and the authority to change production to work out what broke and fix it. A realistic 3am sequence looks like this. The alert fires and is acknowledged. The responder confirms the failure independently, because acting on a false positive wastes the first ten minutes. They check the obvious external causes: DNS, certificate, CDN status, upstream provider status. They check recent change: was there a deployment, a plugin update, a config push, a DNS edit? They look at application logs and the database for connection exhaustion, slow query pile-up, disk full, or a failed migration. Then they either roll back, restart the affected service, scale, or patch forward. Finally they confirm recovery through the same checks that detected the fault, and communicate. Every step in that sequence depends on things a monitoring tool does not have: SSH access, deployment history, knowledge of the application's architecture, permission to roll back, and the ability to write code if the fix requires it. This is the split that leaves so many organisations stranded. The hosting provider will confirm the server is up and decline to look at the application. The agency that built the site is asleep, has no production access, and has no on-call obligation. The alert did its job. Nobody did anything with it. Our guide to [what to do in the first hour of an outage](/services/urgent-website-support-first-hour?stage=Stage) covers the triage sequence in more detail, and if your provider missed its response commitment, [what to do after an SLA breach](/services/website-sla-breach-what-to-do-next?stage=Stage) sets out the remedies worth pursuing. The honest way to evaluate a monitoring arrangement is to ask what happens at 3am on a Sunday of a long weekend. If the answer is that an email arrives in a shared inbox, you do not have monitoring. You have a record of when the outage began. #### Frequently Asked Questions ##### What is website availability monitoring? Website availability monitoring is the continuous, automated verification that a website and its critical functions respond correctly from the locations its users are in. It combines synthetic checks that request pages and run scripted journeys, real user monitoring from actual browsers, log and error rate alerting, and heartbeat checks on background jobs. Monitoring that only requests the homepage and checks for a 200 response will miss most real-world failures. ##### How often should a website be checked for uptime? Critical pages and transactions should be checked every 60 seconds from at least three geographic locations, with secondary pages at 5 minute intervals. Intervals longer than 5 minutes mean short outages go unrecorded entirely, which inflates reported uptime. Pair frequent checks with a confirmation rule requiring two or three consecutive failures from different locations so transient network faults do not trigger false alarms. ##### What is the difference between synthetic monitoring and real user monitoring? Synthetic monitoring sends scheduled requests from external agents and works whether or not anyone is visiting the site, which makes it the only reliable way to detect complete outages. Real user monitoring collects performance and error data from a script running in visitors' browsers, so it shows how the site actually performs by region, device and connection. RUM goes silent during a full outage, so it complements synthetic checks rather than replacing them. ##### What uptime percentage should an enterprise website SLA guarantee? 99.9% is a reasonable commitment for a well managed single-region deployment, allowing roughly 43 minutes of unplanned downtime per month. 99.99% requires redundancy across availability zones and automated failover, and costs considerably more to run. The percentage matters less than the definition behind it: what is measured, at what interval, how many consecutive failures declare an outage, and whether maintenance windows are excluded. ##### Why did my monitoring tool say the site was up when it was down? The most common causes are checking only the homepage, which is often cached at the CDN edge and stays available after the origin fails, and checking only the HTTP status code, since error pages and blank white screens frequently return 200. Checks that ping the server rather than requesting a page will also report success while the web application is refusing connections. Fixing this requires content assertions, checks on multiple paths, and scripted journeys through authenticated and transactional flows. ##### Can monitoring alone prevent downtime? No. Monitoring detects failures; it cannot diagnose or repair them. Restoring service requires someone with production access, knowledge of the application, authority to roll back or patch, and an obligation to respond outside business hours. Monitoring delivers value only when it is attached to a rostered on-call team with the technical capability to act on what it reports. #### Managed uptime and availability monitoring UnDigital runs monitoring and the response behind it as a single service. That means synthetic checks and scripted journeys tuned to your actual critical transactions, certificate, DNS, cron and queue monitoring, alert routing with deduplication and escalation, and a rostered team with production access who investigate and fix rather than forward the alert to you. It applies whether we host your infrastructure or you bring your own AWS, Azure or existing environment. You can read more about our [website uptime monitoring service](/website-uptime-monitoring?stage=Stage) and the [support SLAs for enterprise and government](/services/website-support-slas-for-enterprise-and-government?stage=Stage) that define response and restoration commitments, or start with an infrastructure audit that tells you exactly what your current monitoring is and is not seeing. --- ### Website Emergency Support: Retainer, Ad Hoc or None at All URL: https://undigital.com.au/services/website-emergency-support-retainer-or-ad-hoc **This page compares what a website emergency support retainer actually buys against calling an agency cold mid-incident, and is written for IT managers, digital leads and marketing managers responsible for a site where downtime costs sales, leads or public trust.** #### The moment you need emergency support is the worst moment to procure it Emergency website support is nearly always bought under duress. The site is returning 500s, the phone is ringing, and someone is opening a browser tab to search for an agency that can help right now. That is procurement at the worst possible moment: no time to check references, no time to negotiate terms, no ability to compare rates, and no leverage at all. The uncomfortable part is that the vendor you reach in that state cannot help you quickly even if they want to. They have never seen your server. They do not know whether the site is on a single EC2 instance or behind an autoscaling group, whether the database is RDS or local, whether deploys go through a pipeline or over SFTP, or whether anyone has a current backup. Before they can diagnose anything, they have to discover everything. That discovery happens while your site is down. Organisations often assume the choice is between paying for a retainer they may not use and paying hourly only when something breaks. That framing misses the real variable, which is not cost. It is elapsed time, and elapsed time is decided almost entirely by work done before the incident. #### What actually slows down an emergency response with an unfamiliar vendor In practice, the clock in a cold-start incident is consumed by administration, not engineering. The recurring blockers look like this: - **Nobody can authorise spend.** An unfamiliar vendor will not start billable emergency work without a purchase order, a signed scope or a credit card. Finance is not on shift at 9pm. - **Nobody can grant access.** Server SSH keys sit with a former developer. The cPanel login is in a departed marketing manager's password manager. Registrar access requires a security question nobody remembers. - **The hosting account is not yours.** The site is on a reseller account controlled by the original build agency, and their support desk opens at 9am. - **No one knows what changed.** Without deployment logs, change records or a plugin update history, the responder cannot correlate the failure with a cause and is reduced to guessing. - **The backup position is unknown.** The fastest safe action in many incidents is a restore. If nobody can confirm when the last verified backup ran and what it contains, restoring becomes a risk rather than a remedy. - **There is no monitoring history.** Without response time and error rate data from before the failure, there is nothing to compare against and no way to tell a gradual degradation from a sudden break. None of that is engineering difficulty. It is preparation debt, and it is paid back in minutes of downtime at the least convenient moment. Our guide to the [first hour of an urgent website incident](/services/urgent-website-support-first-hour?stage=Stage) covers what to gather while you are still deciding who to call. #### Comparison: no arrangement, ad hoc hourly, retainer, full SLA The four common arrangements differ far more in behaviour during an incident than they do on an invoice. | Attribute | No arrangement | Ad hoc hourly | Emergency retainer | Full managed SLA | | --- | --- | --- | --- | --- | | Who answers | Whoever replies to a cold enquiry | A vendor you have used before, if available | A named team with your account on file | An on-call roster with a documented escalation path | | Time to first human response | Unpredictable, often next business day | Hours, subject to their current workload | Contracted, typically measured in minutes to hours by severity | Contracted by severity, with after-hours and 24/7 tiers | | Commercial approval needed mid-incident | Yes, before any work starts | Usually yes | No, drawn from prepaid hours | No, covered by the agreement | | Access and credentials | Collected during the outage | Partially held, often stale | Held and periodically verified | Held, verified, plus infrastructure owned or co-managed | | Environment knowledge | None | Whatever they remember from the last job | Documented in a runbook | Continuous, from monitoring, patching and deploys | | Monitoring and detection | You find out from a customer | You find out from a customer | Usually yours to provide | Provider detects and often responds before you report it | | Contractual remedy if they are slow | None | None | Service credits or termination rights, if negotiated | Defined credits, reporting and review obligations | | Cost behaviour | Highest hourly rate, uncapped | Standard or emergency loaded rate | Fixed monthly, drawdown against hours | Fixed monthly, includes prevention as well as response | The pattern is straightforward. Each step up the table converts unknown elapsed time into known elapsed time. That is the product you are actually buying. #### Response time versus resolution time, and why only one can be guaranteed Every credible support agreement guarantees response time and no credible agreement guarantees resolution time. This is not an evasion, and you should be suspicious of any vendor who promises otherwise. **Response time** is the interval between a ticket being raised, or an alert firing, and a qualified engineer acknowledging it and beginning work. It is entirely within the provider's control, because it depends on rostering, alert routing and staffing. It can be measured and it can be breached. **Resolution time** depends on the fault. Restoring a corrupted database from a six-hourly snapshot is a bounded task. A volumetric DDoS, an upstream provider outage, a payment gateway API failure or a zero-day in a CMS core with no patch available are not bounded by anything the provider controls. A vendor who guarantees a fix in four hours is either excluding everything difficult in the fine print or intends to miss. What a mature agreement adds instead of a resolution guarantee is **update cadence**: a commitment to communicate status at defined intervals while an incident is open, for example every 30 minutes for a critical outage and every business day for a low-severity defect. That is the thing stakeholders actually need, because the second-worst experience after an outage is silence during one. If your current provider is failing on either measure, the practical steps are set out in our note on [what to do after a website SLA breach](/services/website-sla-breach-what-to-do-next?stage=Stage). #### Severity definitions that hold up when everyone disagrees about severity Severity arguments happen because the client rates by frustration and the vendor rates by effort. Both are wrong. Severity should be defined by business impact and written down before anything breaks, so that classification is a lookup rather than a negotiation. | Severity | Definition | Examples | Typical target response | | --- | --- | --- | --- | | P1 Critical | Site or a revenue-critical function is unavailable, or a confirmed security compromise is in progress | Site returns 5xx, checkout fails for all users, defacement, active data exfiltration | Minutes, 24/7 | | P2 High | Major function degraded with no workaround, or severe performance loss | Search broken, forms not delivering, page loads exceeding several seconds sitewide | Within business hours, same day, or extended hours by agreement | | P3 Medium | Function impaired with an acceptable workaround | One template rendering incorrectly, a broken integration with a manual fallback | Next business day | | P4 Low | Cosmetic, content or enhancement requests | Typographic issues, minor CSS defects, small content changes | Scheduled into the maintenance queue | Two clauses make this workable. First, the client can raise severity once without justification, which prevents the vendor from quietly downgrading inconvenient tickets. Second, severity is reassessed as facts emerge, so a suspected P1 that turns out to be a single user's caching problem is re-rated with a note rather than an argument. Full worked examples of these definitions appear in our page on [website support SLAs for enterprise and government](/services/website-support-slas-for-enterprise-and-government?stage=Stage). #### Access, credentials and environment knowledge as prerequisites for speed A response time commitment is only honest if the responder can actually act. Before any agreement starts, the following should exist and be verified, not assumed: - SSH or console access to every server, held in a shared vault with named individuals and MFA enforced. - Registrar and DNS control, tested by making a low-risk change, because a DNS emergency at 2am is not the time to discover the registrar login belongs to someone who left in 2019. - CDN and WAF administration, so rules can be changed under attack rather than filed as a support request with a third party. - CMS administrator accounts for each environment, plus database credentials and connection details. - A documented deployment path: repository, branch strategy, build pipeline and rollback procedure, with the rollback actually exercised at least once. - Backup inventory: what is backed up, how often, where it is stored, how long it is retained and when a restore was last tested end to end. - A runbook naming the stack, PHP or Node version, dependencies, cron jobs, integrations and any known fragile areas. - An escalation list with client-side decision makers, including who can authorise taking the site into maintenance mode. Assembling this is usually a day or two of work. Doing it during an outage adds hours to every incident for the life of the relationship, which is why we start engagements with an infrastructure audit rather than a login handover. #### Business hours, after hours and 24/7 cover: what each realistically means Cover windows are frequently misread. Business hours cover means an engineer is at a desk and alerts are watched between, say, 8am and 6pm AEST on business days. An incident at 7pm Friday is picked up Monday morning. That is entirely reasonable for a brochure site and entirely unreasonable for a retailer in November. After-hours cover means someone carries a pager outside business hours and responds to alerts above an agreed severity. Response is slower than during the day, because a person has to wake up, get to a laptop and load context. A target of 30 to 60 minutes overnight for a P1 is realistic. Fifteen minutes, overnight, from a small team, usually is not. True 24/7 cover requires a roster, with primary and secondary on-call, handover between people and time zones, and alerting that routes to a human rather than an inbox. A distributed team across Australian and Asian time zones makes this considerably more sustainable than asking one Sydney engineer to be permanently awake. Whatever window you buy, it is worth nothing if detection is slow. If you learn about outages from customers, your effective response time is however long it takes someone to complain plus however long the vendor takes to answer. Pair any cover window with [availability monitoring that combines synthetic checks with real user data](/services/website-availability-monitoring-synthetic-rum-alerting?stage=Stage) so the clock starts at the failure, not at the phone call. #### Post-incident review and stopping the same outage twice Ad hoc emergency work has a structural flaw: the vendor is paid to make the symptom go away and is not paid to prevent it recurring. Restarting PHP-FPM clears a memory exhaustion event. It does not address the unbounded query that caused it, so the same call happens again in a fortnight, at the same hourly rate. A retainer or SLA should include a written post-incident review for every P1 and significant P2, produced within a few business days, covering: - A timeline from first symptom to resolution, with timestamps for detection, acknowledgement, diagnosis and fix. - The direct technical cause, stated plainly. - The contributing conditions, for example missing alerting thresholds, an unpatched dependency or an undocumented manual change. - Remedial actions with owners and dates, separated into immediate fixes and structural changes. - What detection would have caught it earlier, and whether that check is now in place. Over a year of these, the character of the relationship changes. Emergencies become rarer because the causes are being removed rather than reset. That is the strongest financial argument for a retainer, and it is invisible on a per-incident invoice. It is also the practical difference between [break/fix emergency support](/services/break-fix-and-emergency-website-support?stage=Stage) and a managed arrangement where prevention and response come from the same team. #### Choosing between the three arrangements Ad hoc hourly is defensible when the site is not commercially critical, you hold all credentials, and an outage lasting a day is an inconvenience rather than a loss. It is a genuine option and not everyone needs more. An emergency retainer suits organisations with an in-house team that handles routine work but has no depth at 11pm, and no one who has restored a production database under pressure. You are buying a phone number that answers and a team that already knows the stack. A full managed SLA suits organisations where the website drives sales or leads, where government or enterprise procurement requires documented response commitments, and where there is currently a gap between the hosting provider who will not touch the application and the build agency who has moved on. When the infrastructure and the application expertise sit with one accountable party, there is nobody left to point at. #### Frequently Asked Questions ##### What is website emergency support? Website emergency support is a service that responds to urgent faults such as outages, security compromises, failed deployments and severe performance degradation, usually outside normal project work and often outside business hours. It can be purchased ad hoc at an hourly rate, as a prepaid retainer, or as part of a managed service agreement. The critical difference between the models is how quickly a qualified engineer can begin work, which depends far more on prior access and environment knowledge than on hourly rate. ##### What is the difference between break/fix support and a website support SLA? Break/fix support is transactional: you report a problem, the vendor quotes or bills hourly, and the engagement ends when the symptom is gone. A website support SLA is a continuing agreement with defined severity levels, contracted response times, agreed cover hours and remedies if those commitments are missed. Break/fix is priced per incident and rarely addresses root causes, while an SLA includes monitoring, prevention and post-incident review. ##### Should an SLA guarantee how long it takes to fix my website? No. Response time can be guaranteed because it is within the provider's control, but resolution time depends on the nature of the fault, third-party systems and factors such as upstream outages or unpatched vulnerabilities. A credible agreement guarantees acknowledgement within a defined window and commits to a communication cadence while the incident stays open. Treat any promised fix time with scepticism and read the exclusions carefully. ##### How quickly can a new vendor help if my website is down right now? An unfamiliar vendor typically needs commercial approval, server and CMS credentials, DNS and registrar access, and an understanding of the deployment and backup position before any diagnosis begins. That preparation commonly takes longer than the technical fix itself. If you are in an incident now, gather hosting details, recent change history and the last known-good backup date before you make the call, because it materially shortens the response. ##### Is a support retainer worth it for a site that rarely breaks? It depends on what an hour of downtime costs you, not on how often incidents occur. If the site generates sales or leads, or serves a public obligation, the retainer is insurance against the unbounded cost of a cold-start response at the worst time. If the site is informational and a day offline is tolerable, ad hoc hourly support is a reasonable choice. ##### Can emergency support cover a website someone else built? Yes, and it is a common starting point. It begins with an infrastructure and code audit to document the stack, verify access, test the backup and restore path and identify the fragile areas, because response commitments cannot honestly be made against an environment nobody has examined. Once that baseline exists, severity definitions and response times can be agreed with confidence. #### Put emergency website cover in place before you need it UnDigital provides managed hosting and website management under defined support SLAs for enterprise, government and growing businesses, including after-hours and 24/7 cover with documented severity levels, response targets and post-incident review. Because we hold both the infrastructure and the development capability, there is no handover between a host who will not touch the application and a developer who cannot reach the server. Engagements start with an infrastructure audit so the response commitments we make are ones we can keep. Explore our [managed hosting for enterprise websites](/managed-hosting?stage=Stage) or get in touch to scope cover for your site. --- ### Website Governance, Compliance & Risk Management URL: https://undigital.com.au/services/website-governance-compliance-and-risk-management **Structured processes, compliance checks, and risk mitigation to meet [enterprise and government standards](/specialisations). We provide [Website Governance, Compliance & Risk Management](/services) to [Sydney, Brisbane and Sunshine Coast](/contact).** ##### Why Governance Matters Websites are more than marketing tools—they’re business-critical systems. Compliance, auditability, and risk management are non-negotiable for large organisations. We help you stay compliant, auditable, and resilient while maintaining speed and flexibility. ##### Our Services Include - Governance frameworks for website operations - Compliance with accessibility & security standards - Risk identification & mitigation plans - Vendor management & accountability - Reporting for executives & boards > “UnDigital turned a chaotic website into a structured, compliant, and low-risk asset.” – Marketing Director, VCCC ##### Process - Governance assessment & framework creation - Risk and compliance audit - Remediation & optimisation - Executive reporting & dashboards - Continuous improvement --- ### Website Managed Services: What's Actually Included, and What Isn't URL: https://undigital.com.au/services/website-managed-services-what-is-included **This page defines what "website managed services" should actually cover across infrastructure, platform, application and content, where hosting providers and build agencies each stop, and which inclusions and exclusions belong in the agreement. It is written for IT managers, digital leads and marketing managers who are buying or renegotiating an ongoing website arrangement.** #### What Buyers Mean by Managed Services, and What Vendors Usually Mean When an organisation says it wants its website managed, it means something close to this: somebody else is accountable for the site being up, current, secure and fixed when it breaks, without the organisation having to work out whose job it is. When a vendor says "managed", it usually means something much narrower. A hosting company means the server is patched and the disk has not filled up. A build agency means it will look at tickets during business hours if you have hours left on the retainer. A cloud platform means the runtime is abstracted away from you. All three are legitimate services. None of them is what the buyer described. The gap is not usually dishonesty. It is that the word covers four different layers of a system, and most contracts silently apply to one of them. #### The Four Layers of a Managed Website Every website in production sits on four layers. Work that happens on one layer will not fix a fault on another, and each layer is typically owned by a different party unless you deliberately consolidate them. | Layer | What it includes | Typical failure | Who usually owns it | | --- | --- | --- | --- | | Infrastructure | Servers or containers, OS packages, web server, DNS, TLS certificates, firewall, CDN, backups, monitoring | Disk full, expired certificate, DDoS, kernel CVE, failed backup job | Hosting provider or your own cloud account | | Platform | PHP or Node runtime version, database engine, CMS core, framework, extensions and modules | PHP 8.1 reaching end of life, CMS major version out of support, unpatched plugin | Nobody, in most arrangements | | Application | Custom modules, theme and template code, integrations, forms, search, third party APIs | Payment gateway API change, broken form handler, integration silently failing | The agency that built it, if still engaged | | Content | Pages, media, redirects, metadata, editorial workflow, accessibility of published content | Broken links after a restructure, 15MB hero images, missing redirects | The internal marketing team | The interesting layer is the second one. Platform maintenance is where almost every serious incident originates, and it is the layer with no natural owner. Your host will not upgrade a CMS major version. Your build agency will not do it unless someone raises a purchase order. So it sits, and the site drifts out of support until a penetration test or an insurance questionnaire forces the issue. #### What a Hosting Provider Will and Will Not Touch A competent hosting provider takes responsibility to the boundary of the operating system and, sometimes, the web server configuration. Inside that boundary they do genuinely useful work: OS package updates, resource monitoring, network level filtering, snapshotting the volume. What they will not do, in almost every case: - Update your CMS core, modules, plugins or themes - Read an application error log and diagnose why a form stopped submitting - Test that a backup actually restores into a working site rather than merely existing - Change a PHP version, because it might break your application and that is not their risk to carry - Review a CVE announcement and decide whether your specific configuration is exposed - Touch code, ever This is why "managed hosting" from a volume provider and [managed hosting for an enterprise website](/managed-hosting?stage=Stage) are different products sharing a name. One manages a server. The other manages the thing the server exists to run. #### What a Build Agency Will and Will Not Touch The agency that built the site knows the codebase, which makes it the right party for application work. The problem is structural rather than technical. Build agencies are organised around projects: scoped, funded, delivered, invoiced, closed. Ongoing operational responsibility does not fit that shape. In practice this means: - No monitoring, or monitoring that pages nobody outside business hours - No defined response or resolution targets, only "we will get to it" - Dependency updates deferred because they are unbillable and invisible to the client - The developer who knows your build leaves, and institutional knowledge leaves with them - Infrastructure treated as somebody else's problem, because the agency has no server discipline #### The Gap Between Them, and Who Pays for It The gap is the platform layer plus everything time critical. It shows up at the worst possible moment: a critical vulnerability is announced for your CMS, and the host says it does not touch the application while the agency says it needs a scoped quote and has capacity next month. The organisation pays for the gap three ways. It pays in unplanned emergency work at premium rates, it pays in accumulated upgrade debt that eventually becomes a re-platform project, and it pays in risk it did not know it was carrying. When an incident happens, the first hour is spent working out who is responsible rather than fixing anything, which is why [break/fix and emergency support](/services/break-fix-and-emergency-website-support?stage=Stage) is so much more expensive than the maintenance that would have prevented it. #### Scope Comparison: Hosting Only, Management Only, Full Managed Service There are three coherent ways to buy this, and the right one depends on whether you already own infrastructure you intend to keep. | Responsibility | Hosting Only | Management Only | Hosting + Management | | --- | --- | --- | --- | | Server provisioning and OS patching | Included | Client or client's cloud provider | Included | | Backups and tested restores | Included | Configured and verified on client infrastructure | Included | | Uptime and performance monitoring | Included | Included | Included | | WAF, DDoS mitigation, TLS lifecycle | Included | Configured on client's Cloudflare or AWS account | Included | | CMS core, module and plugin updates | Not included | Included | Included | | Runtime and database version upgrades | Not included | Included, coordinated with client's infrastructure team | Included | | Application bug fixes and small changes | Not included | Included within agreed hours | Included within agreed hours | | Incident response against defined targets | Infrastructure only | Application only | End to end, single accountable party | | Best suited to | Teams with in-house developers | Organisations committed to their own AWS, Azure or Vercel environment | Organisations that want one vendor accountable for the whole stack | #### Inclusions Worth Writing Into the Agreement Vague scope is the reason most managed arrangements disappoint. These are the clauses worth insisting on, each of which is falsifiable and therefore enforceable. - **Backup frequency and retention, plus a restore test cadence.** A backup that has never been restored is a hypothesis. Ask how often a restore is actually performed into a working environment. - **Named response and resolution targets by severity.** P1 through P4, in hours, with business hours and after hours defined separately. Vague "priority support" is not a target. - **Uptime commitment with a stated measurement method.** A 99.9% figure means nothing unless you know what is being checked, from where, and how often. See how [support SLAs for enterprise and government](/services/website-support-slas-for-enterprise-and-government?stage=Stage) are typically structured. - **Security patching windows.** Critical CVEs applied within a stated number of hours of a vendor release, with emergency patching outside the normal cycle for actively exploited vulnerabilities. Ongoing [CVE scanning and vulnerability monitoring](/cve-scanning-and-vulnerability-monitoring?stage=Stage) should be continuous, not annual. - **Platform currency.** An explicit commitment that CMS, framework, runtime and database will be kept on supported versions, with major upgrades planned and budgeted rather than deferred indefinitely. - **Reporting.** Monthly, showing uptime, patches applied, vulnerabilities found and closed, hours consumed and work completed. - **Escalation path.** A named contact and a phone number, not a shared inbox. - **Exit terms.** Data, code, configuration and credentials returned in a usable form within a stated period. #### Exclusions You Should Expect, and Which Ones Are Reasonable A managed services agreement with no exclusions is either mispriced or misleading. Reasonable exclusions include new feature development, design work, content production, third party licence fees, integrations with systems the vendor does not control, and faults caused by changes the client made without notice. Exclusions that should concern you are the ones that hollow out the core service: - Security patching listed as chargeable rather than included - Incident response only during business hours on a site that transacts around the clock - Major version upgrades excluded entirely with no plan for how they will ever happen - Backups included but restores billed as project work - Any clause that makes the vendor the sole judge of whether an incident is its fault Third party plugin conflicts deserve a note. A vendor cannot be liable for a commercial plugin's defect, but it should be responsible for detecting the conflict, isolating it and telling you what to do next. #### How Hours, Retainers and Fair Use Actually Work Most agreements combine a fixed operational component with a pool of hours. The operational component covers monitoring, patching, backups and incident response, and it is not drawn from the hours. The hours cover discretionary work: content changes, small enhancements, integration adjustments, reporting requests. Three questions decide whether the structure works for you. Do unused hours roll over, and for how long? What is the rate for hours beyond the pool, and is it the same rate as the retainer implies? Is proactive maintenance drawn from the pool, or funded separately? If patching consumes discretionary hours, your team will quietly deprioritise it, which defeats the purpose. Fair use clauses are reasonable in principle. They should be expressed as a number, not as a mood. "Reasonable ongoing support" is not a scope. "Up to twelve hours per month, with additional hours quoted in advance" is. #### Access and Handover: Secure These Before You Sign The organisation should own the assets, and the vendor should have access to them. Arrangements often invert this, and it only becomes apparent when the relationship ends. - Domain registrar account in the organisation's name, with the organisation as registrant contact - DNS zone under the organisation's control, or transferable on request - Git repository owned by the organisation, with full commit history - Cloud accounts (AWS, Azure, Cloudflare, Vercel) billed to and owned by the organisation where the Management Only model applies - SSL certificate ownership and renewal responsibility documented - Third party licences held in the organisation's name, not the agency's - Documented deployment process, environment variables and infrastructure configuration If any of these are currently held by an incumbent who is not cooperating, that is a normal starting condition rather than a blocker. It is the ordinary first phase of a [migration to a new vendor](/services/website-migration-to-a-new-vendor?stage=Stage), and it is worth resolving before an incident forces it. #### Frequently Asked Questions ##### What is included in website managed services? A full managed service covers infrastructure (servers, backups, TLS, firewall, CDN, monitoring), platform maintenance (CMS core, modules, runtime and database versions), application support (bug fixes and small changes against defined response targets), and reporting. It should not usually include new feature development, design, content production or third party licence fees, which are scoped and quoted separately. If security patching or restores are chargeable extras, the agreement is a hosting contract with a support option rather than a managed service. ##### What is the difference between website hosting and website management? Hosting covers the environment the site runs in: the server, operating system, network, backups and availability. Management covers the site itself: CMS and dependency updates, security patching, performance tuning, bug fixes and content support. They are frequently sold by different companies, which is why so many organisations have hosting and no management, and discover the gap only when a vulnerability is announced. ##### Who is responsible when a website goes down, the host or the developer? It depends on the cause, which is exactly the problem with splitting the two. If the outage is a full disk or a network fault, it is the host. If it is a fatal application error after a deployment or a database query lock, it is the developer. Where one vendor holds both layers, the question does not need to be answered before work starts, which is normally the single largest reduction in time to resolution. ##### Do I still need managed services if my site runs on AWS or Vercel? Yes, because those platforms manage the layer beneath your application, not your application. AWS will keep an EC2 instance running but will not upgrade your CMS, review a dependency CVE or fix a broken integration. This is the case for a Management Only arrangement, where the organisation keeps its own cloud account and billing relationship and a managed services partner takes responsibility for everything running on top of it. ##### How many hours per month should a website management retainer include? There is no universal number, because it depends on the size of the codebase, the number of integrations, editorial volume and how current the platform is. A useful test is whether proactive maintenance is funded outside the discretionary hours. If patching, monitoring and backups draw down the same pool as content changes, the maintenance will lose that competition every month. ##### What should I check before signing a managed website agreement? Confirm that you own the domain, DNS, code repository and third party licences, that response targets are stated in hours by severity, that backup restores are tested rather than merely scheduled, and that major version upgrades have a named plan rather than a blanket exclusion. Also confirm the exit terms: what you receive, in what format, and within how many days of termination. #### Managed Website Services from UnDigital UnDigital is both the hosting provider and the development team, which removes the boundary that most managed arrangements are built around. Engagements run under three models: Hosting + Management for organisations that want one accountable party for the whole stack, Hosting Only for teams with in-house developers, and Management Only for organisations committed to their own AWS, Azure or Vercel environments. Every engagement starts with an infrastructure audit, and pricing is scoped from what that audit finds rather than published as a plan. The work covers WordPress, Silverstripe, Drupal, Craft, Statamic, headless builds on Storyblok, Sanity and Contentful, and custom applications on Next.js, Nuxt, Laravel and Node, with 24/7 monitoring, six-hourly backups, WAF and DDoS protection and ongoing [security management and monitoring](/services/website-security-management-and-monitoring?stage=Stage) on dedicated Australian infrastructure. If your current arrangement covers the first layer and none of the others, an audit will tell you precisely where the gaps are. --- ### Website Migration Between Hosts: A Zero-Downtime Cutover URL: https://undigital.com.au/services/website-migration-between-hosts-zero-downtime-cutover **This page explains how a website migration between hosting providers actually works, from discovery through DNS cutover to rollback, and is written for IT managers, digital leads and agency owners who need the move to happen without an outage.** Most website migrations do not fail at the technical step people worry about. The database copies fine. The files transfer fine. What goes wrong is a CAA record nobody checked, a payment gateway webhook still pointing at the old IP, a TTL of 86400 that was never lowered, or an SSL certificate that cannot be issued because the validation challenge is being served by the server you just left. These are all sequencing problems, and sequencing is the part that gets skipped when three parties are involved and none of them owns the whole job. #### What people mean by migration, and the four kinds that get confused "Website migration" is used to describe four quite different projects with different risk profiles. Being clear about which one you are doing changes the entire plan. | Type | What changes | Main risk | Typical rollback | | --- | --- | --- | --- | | Host-to-host (lift and shift) | Infrastructure only. Same code, same CMS version, same domain. | DNS, certificates, environment configuration drift | Repoint DNS to the old host | | Platform or CMS replatform | Application, templates, content model, URLs | Content fidelity, URL mapping, lost search equity | Hard. Content has usually moved on | | Domain change | Hostname, canonical URLs, email, certificates | Redirect coverage, email deliverability | Partial only. Links are already in the wild | | Vendor change | Who holds credentials, code and accountability | Handover gaps, undocumented infrastructure | Commercial, not technical | This page is about the first one, the host-to-host cutover, because it is the one that is supposed to be invisible to users and the one most often treated as trivial. If you are also changing who looks after the site afterwards, the handover considerations in [website migration to a new vendor](/services/website-migration-to-a-new-vendor?stage=Stage) apply on top of everything below. #### Discovery: inventory everything before you touch anything A migration plan is only as good as the inventory it is built on. The failure mode is discovering a dependency during the cutover window, at which point you are debugging under time pressure with the site half-moved. Before any file is copied, the inventory should cover: - Runtime versions: PHP or Node major and minor version, extensions loaded, opcache settings, memory limits, max_execution_time. - Database engine and version, character set and collation, and any stored procedures, triggers, events or full text indexes. - Web server configuration: virtual hosts, rewrite rules, custom headers, request body size limits, reverse proxy behaviour. - Cron jobs and scheduled tasks, with their schedules and the user they run as. These are the single most commonly forgotten item. - Outbound mail: SMTP relay, credentials, sending domain, and whether the application sends directly or via an API. - Environment variables and secrets, including API keys that may be IP-bound. - Every DNS record on the zone, not just the A record. - Search, queue, cache and object storage services: Elasticsearch, Redis, Memcached, S3 buckets. - Scheduled integrations and anything that connects inbound on a fixed IP. Write the inventory down. The same document becomes the verification checklist on cutover night. #### DNS reality: TTL, propagation and the records you can break DNS is where a zero-downtime cutover is won or lost, because it is the only part of the process you cannot fully control once it is in motion. ##### Reduce TTL days in advance If the A record TTL is 3600 or 86400, resolvers will keep serving the old IP for that long after you change it. Reduce the TTL on the records you intend to change to 300 seconds at least 48 hours before cutover, so that the old long TTL has fully expired from caches before the short one takes effect. Raise it again a week after the move. Note that some recursive resolvers ignore very low TTLs and enforce a floor, so plan for a tail of traffic hitting the old origin regardless. ##### Records that are not the website The most common migration-caused outage is not the website at all, it is email. If the zone is being recreated on a new DNS provider rather than edited in place, every record has to be reproduced exactly: - MX records and their priorities. - SPF TXT record, including every include: for marketing platforms, CRMs and transactional senders. - DKIM selectors, which are usually CNAMEs with unguessable names and will not be rediscovered if lost. - DMARC policy at _dmarc. - Domain verification TXT records for Google, Microsoft and any SaaS platform. - CAA records, which will silently block certificate issuance from a certificate authority that is not listed. If your old host used DigiCert and your new stack uses Let's Encrypt, issuance fails until the CAA record allows letsencrypt.org. - SRV records for services such as Microsoft 365 autodiscover. Export the full zone file from the current provider and diff it against the new zone before you change the nameservers. Do not rebuild from memory. #### Certificates issued before cutover, not after A certificate must be valid and installed on the new origin before any traffic reaches it. The complication is that ACME HTTP-01 validation serves a challenge file over port 80 on the hostname being validated, and that hostname still resolves to the old host. There are three practical ways through this. - **DNS-01 validation.** Prove control by publishing a TXT record at _acme-challenge. This works before cutover and is the cleanest option, and it is the only way to issue a wildcard. - **Issue on a temporary hostname, then reissue.** Acceptable for testing, but leaves a gap at cutover. - **Import an existing certificate and private key** from the current host if it is a commercial certificate with time remaining. Check HSTS before you go anywhere near the cutover. If the site sends Strict-Transport-Security with a long max-age, or the domain is on the HSTS preload list, a certificate error on the new origin is not a warning users can click through. It is a hard block with no bypass. Verify the full chain with an external checker, not just a browser on a machine that may already trust an intermediate. #### Database strategy: dump, delta sync or read-only window The database is the only asset that changes while you are moving it. How you handle that depends entirely on how much write activity the site has. | Approach | Suits | Write downtime | Complexity | | --- | --- | --- | --- | | Full dump and restore | Brochure sites, low-write CMS sites | Length of the dump and restore | Low | | Seed dump plus final delta | Large databases with moderate writes | Minutes | Medium | | Replication, then promote | Ecommerce, transactional, high write volume | Seconds | High | | Read-only window | Sites where forms and checkout can pause briefly | Writes blocked, reads unaffected | Low to medium | For MySQL and MariaDB, take the seed dump with mysqldump --single-transaction --quick on an InnoDB database so you get a consistent snapshot without locking tables, then either configure the new server as a replica using binary log position or GTIDs, or take a short final dump during the window. For PostgreSQL, logical replication from the old primary to the new instance lets you promote with a very small gap. Whichever route you choose, confirm character set and collation match. A migration from utf8 to utf8mb4 that is not handled deliberately will mangle emoji and non-Latin characters in a way that is tedious to unwind later. #### Files, media and user uploads Application code should come from version control and be deployed to the new environment, not copied from the old server. Uploaded assets are different: they only exist on disk or in object storage. Sync them in two passes. Run a full rsync -a days before cutover while the old site is live, then a second incremental pass during the window to pick up anything added since. Preserve ownership and permissions, and check for symlinks that point at absolute paths which will not exist on the new host. If assets are already in S3 or equivalent, you may be able to leave the bucket in place and only change the credentials and CORS policy, which removes a large chunk of transfer time. Verify file counts and total bytes on both sides before declaring the sync complete. #### Third-party dependencies that break quietly These are the items that pass every test on cutover night and fail three days later when a scheduled job runs. - **IP allowlists.** Payment gateways, bank feeds, government APIs, partner SFTP endpoints and some CRMs restrict access by source IP. The new egress IP has to be registered in advance, and some of these take a week to action. - **Webhooks.** Inbound callbacks from payment providers, form platforms and CRMs are configured in the remote system. If they resolve by hostname they will follow DNS. If they are pinned to an IP, they will not. - **SSO.** SAML and OIDC configurations contain assertion consumer service URLs, redirect URIs and signing certificates. A new certificate on the service provider side needs the identity provider updated. - **Outbound email.** If the application sends via the local MTA, a new server IP has no sending reputation and SPF will fail unless updated. Route transactional mail through an authenticated relay. - **CDN and WAF.** If the site sits behind a proxy, the origin IP changes while the public IP does not, which is helpful. Firewall rules on the new origin must still allow only the proxy's ranges, and the application must read the real client IP from the forwarded header. Our notes on [running enterprise sites behind Cloudflare](/services/benefits-of-cloudflare-for-enterprise-websites?stage=Stage) cover the configuration in more detail. #### Staging verification before you move production The new environment should run the full site, with production data, under its real hostname via a hosts file override, before cutover is scheduled. Test with the hostname forced locally rather than on a temporary subdomain, because absolute URLs, cookie domains, canonical tags and CSRF origin checks all behave differently otherwise. The verification pass should cover authenticated sessions, admin login, a complete checkout or form submission end to end, file upload, search, scheduled task execution, email delivery, 404 and 500 handling, redirect rules, and a crawl of the site compared against a crawl of production to catch status code differences. Make sure staging is blocked from indexing while it is public, and equally make sure that block is removed before the site goes live. A noindex header carried into production is one of the more painful self-inflicted migration injuries. #### The cutover window itself A well-prepared host-to-host cutover is short, because everything expensive has already been done. A workable sequence: - **T minus 72 hours.** Lower TTLs. Confirm certificates issued and installed. Confirm IP allowlist changes applied. - **T minus 24 hours.** Full file sync. Seed database restore. Replication running or delta process tested. - **T minus 1 hour.** Freeze content editing. Notify stakeholders. Disable cron on the new environment so nothing fires early. - **T zero.** Put the old site into read-only mode or maintenance. Run the final delta sync and incremental file pass. Verify row counts on key tables. - **T plus 10 minutes.** Run the verification checklist against the new origin with a hosts override. Do not change DNS until it passes. - **T plus 20 minutes.** Update the A or CNAME record. Enable cron on the new environment. - **T plus 25 minutes.** Watch logs on both origins. Traffic should appear on the new one within a few minutes and taper off the old one over the following hour. - **T plus 2 hours.** Confirm old origin traffic has fallen to near zero. Check error rates, response times and transaction volume against the pre-migration baseline. Keep the old origin serving the old site during the tail, rather than switching it off or showing a maintenance page. Visitors on stale DNS should get a working site, not an error. The only thing that must not happen is writes landing on the old database, which is what the read-only mode is for. #### Rollback criteria and how long to keep the old environment Decide the rollback triggers before the window opens, and write them as thresholds rather than judgement calls. Typical criteria: error rate above an agreed percentage of requests, checkout or lead form success rate materially below baseline, median response time above an agreed figure, or any data integrity problem at all. Rollback is repointing DNS back to the old origin and lifting read-only mode. That is clean only while the new environment has taken no writes you cannot afford to lose. Once orders or form submissions have landed on the new database, rollback becomes a data reconciliation exercise instead, which is why the first two hours matter so much more than the next two days. Keep the old environment running and paid for at least 30 days. You will want it for anything that turns out to have been on that server and in nobody's inventory, and for log comparison when someone asks why a metric moved. #### After the cutover The migration is not finished when the site loads. The week afterwards is where the quiet failures surface. - Confirm backups are running on the new environment and, more importantly, restore one to prove it works. - Re-point or recreate [uptime and availability monitoring](/services/website-availability-monitoring-synthetic-rum-alerting?stage=Stage), including SSL expiry checks, and confirm alerts reach a human. - Compare server response times and Core Web Vitals against the pre-migration baseline you captured. A faster server with a cold object cache can look slower for the first day. - Check Search Console for crawl errors and a spike in 404s or 5xx responses, and resubmit the sitemap. - Watch for redirect chains introduced by new web server rules, particularly http to https to www sequences that should be a single hop. - Verify logs, log rotation and retention are configured, and that security patching is scheduled rather than assumed. #### Frequently Asked Questions ##### How long does a website migration between hosts take? Preparation for a typical CMS site takes one to three weeks, covering discovery, environment build, data sync and staging verification. The cutover window itself should be under an hour for a lift and shift, and under a few minutes of write downtime if database replication is used. Large ecommerce platforms, complex integrations or multisite estates extend the preparation phase, not usually the cutover. ##### Can a website really be migrated with zero downtime? Zero downtime for visitors is achievable, because both origins serve the same site during DNS propagation and users are never sent to a broken server. What cannot be avoided entirely is a short write freeze while the final database delta is applied, typically seconds to a few minutes depending on the strategy. The practical goal is zero visible outage and a write pause short enough that nobody notices. ##### Will migrating to a new host affect SEO rankings? A same-domain host migration should have no ranking impact if URLs, status codes, redirects and robots directives are identical before and after. Rankings suffer when a staging noindex survives into production, when redirect rules change silently, or when response times degrade on the new infrastructure. Crawl the site before and after and compare status codes URL by URL to prove nothing moved. ##### Why do I need to lower the DNS TTL before migrating? Recursive resolvers cache DNS records for the duration of the TTL, so a record with a TTL of 86400 can keep sending traffic to the old server for a full day after you change it. Dropping the TTL to 300 seconds at least 48 hours ahead means caches expire quickly once the change is made. Raise the TTL again about a week after the migration to reduce unnecessary lookups. ##### Does migrating website hosting affect my email? It does if email is hosted on the same server or if the DNS zone is recreated at a new provider rather than edited in place. MX, SPF, DKIM and DMARC records must be reproduced exactly, and DKIM selectors in particular are difficult to recover once lost. Export the full zone file first and diff it against the new zone before changing nameservers. ##### Who is accountable if something breaks during a migration? That depends entirely on how the work is contracted. When an old host, a new host and a separate development team are each responsible for one piece, nobody owns the sequencing, and during an incident each party can reasonably point at the others. A single provider holding both the infrastructure and the application work removes the gap, which is the main argument for consolidating migration and ongoing hosting with one team. #### Talk to UnDigital about migrating and then managing your hosting UnDigital runs host-to-host migrations for enterprise, government and ecommerce sites on WordPress, Silverstripe, Drupal, Magento and custom applications, and then keeps running them afterwards under an SLA. That matters more than it sounds. The team that built the inventory, mapped the DNS zone and watched the logs on cutover night is the same team patching the server six months later, so nothing gets lost in a handover that never happens. Every engagement starts with an infrastructure audit of the current environment. If you are still deciding where the site should land, our guidance on [what to look for in managed website hosting in Australia](/services/managed-website-hosting-australia-what-to-look-for?stage=Stage) and [how to evaluate a managed web services provider](/services/how-to-evaluate-a-managed-web-services-provider?stage=Stage) is a reasonable place to start, and the [managed hosting service](/managed-hosting?stage=Stage) itself is available as hosting plus management, hosting only, or management only if you are bringing your own AWS or Azure infrastructure. --- ### Website Migration to a New Vendor URL: https://undigital.com.au/services/website-migration-to-a-new-vendor **Seamlessly transition your website, systems, and support to a new partner with zero downtime, protected data, and full operational continuity. We provide [Website Migration Services](/services) to [Sydney, Brisbane and Sunshine Coast](/contact).** ##### Why Website Vendor Migrations Are High-Risk Changing website vendors isn’t just a contract change. It’s a transfer of responsibility for a business-critical system. When handled poorly, migrations lead to: - Unexpected downtime - Security gaps - Lost data or broken functionality - [SEO](https://undigital.com.au/optimiseo/) and performance degradation - Finger-pointing between old and new vendors [Enterprise and government organisations](/specialisations) can’t afford disruption — and that’s why vendor migration needs to be treated as a controlled transition, not a handover. ##### Why Organisations Decide to Change Vendors Most organisations don’t migrate vendors lightly. Common triggers include: - Slow or unresponsive support - Missed SLAs or unresolved issues - Security concerns or failed audits - Loss of confidence in the incumbent vendor - Internal capability or leadership changes By the time teams start searching for “website migration to new vendor”, the decision is usually already made. The remaining question is how to do it safely. ##### The Hidden Complexity of Vendor Migration Enterprise websites often include: - [Custom CMS](/technology) functionality - Third-party integrations - [Hosting and infrastructure](/services) dependencies - Security configurations and access controls - Historical technical debt Without visibility and planning, migrations expose risk rather than reduce it. The most common failure point? Assuming the new vendor can “just take over.” ##### How UnDigital Handles Vendor Migrations We specialise in taking over complex, high-risk digital environments. Our approach focuses on: - Stability first - Security throughout - Clear ownership - No surprises We don’t rush handovers. We engineer confidence into the transition. ##### Our [Website Vendor Migration Services](/services) Discovery & Risk Assessment - Review of current website, CMS, and infrastructure - Identification of high-risk components - Access, credential, and dependency mapping Transition Planning - Controlled migration plan with clear milestones - Downtime and risk minimisation strategy - Coordination with outgoing vendor where required Technical & Operational Takeover - Secure access transfer - Monitoring and alerting implementation - Immediate issue remediation Post-Migration Stabilisation - Performance and reliability tuning - Security hardening and validation - Backlog triage and prioritisation ##### Why This Matters at an Enterprise Level Vendor migrations often coincide with: - Audits - Reviews - Strategic resets - New leadership A successful migration demonstrates: - Strong governance - Risk awareness - Operational maturity - Confidence in digital leadership A failed one becomes highly visible — very quickly. ##### Who This Is For This service is designed for: - Government departments and agencies - Enterprise organisations with business-critical websites - Teams replacing underperforming vendors - Organisations inheriting complex or legacy platforms - Stakeholders accountable for uptime and security If you’re researching vendor migration, you’re looking for certainty, not shortcuts. ##### Common Questions **Will there be downtime?** Our migrations are designed to minimise or eliminate downtime wherever possible. **Do we need cooperation from the outgoing vendor?** Sometimes, but not always. We plan for both scenarios. **Will SEO or performance be affected?** When handled correctly, performance and stability often improve post-migration. **Is this the same as a rebuild?** No. Vendor migration is about control and continuity, not redesign — unless you choose otherwise. ##### Next Step Changing website vendors doesn’t have to be stressful. If you’re planning a transition, we can help you: - Reduce risk - Maintain continuity - Improve reliability - Regain confidence in your digital operations --- ### Website SLA Breach: What to Do Next URL: https://undigital.com.au/services/website-sla-breach-what-to-do-next **If your digital agency has failed to meet agreed service levels for your website or application, the real risk isn’t just downtime — it’s trust, accountability, and long-term exposure. We provide [Enterprise Website SLA Services](/services) to [Sydney, Brisbane and Sunshine Coast](/contact).** ##### Why Organisations Start Searching for “SLA Breach” Most organisations don’t search for SLA breaches unless something has gone wrong. Common triggers include: - Repeated website outages - Slow or unresolved incident response - Missed uptime or performance targets - Poor communication during critical events - Escalations from internal stakeholders or customers If you’re here, it’s likely your website or application SLA has been breached — and confidence in your current provider is eroding. ##### What a Website SLA Breach Actually Means A Service Level Agreement (SLA) defines how your website or application should be: - Supported - Monitored - Maintained - Responded to during incidents An SLA breach occurs when those commitments are not met — whether that’s uptime, response times, resolution times, or reliability guarantees. For digital platforms, SLA breaches are not just technical failures — they are business risks. ##### Why Website & App SLA Breaches Are So Damaging Unlike internal systems, websites and applications are: - Public-facing - Customer-impacting - Revenue and reputation critical When SLAs are breached, the impact can include: - Loss of customer trust - Reputational damage - Internal escalation and reporting pressure - Increased scrutiny from leadership or auditors Often, the biggest issue isn’t the outage — it’s the lack of confidence that it won’t happen again. ##### Common Reasons Agencies Breach Website SLAs In our experience, SLA breaches often stem from: - Overpromised SLAs with under-resourced teams - Poor monitoring and alerting - Reactive rather than proactive support - Fragmented responsibility across vendors - Lack of clear ownership during incidents Many agencies are good at building websites — far fewer are good at operating them under SLA pressure. ##### What Happens After an SLA Breach Once an SLA has been breached, organisations often face: - Internal reviews or post-incident reports - Pressure to justify continued vendor engagement - Increased scrutiny on future outages - A need for clearer governance and accountability This is usually the point where teams ask: *“Do we actually have the right partner managing our website?”* ##### How UnDigital Prevents SLA Breaches UnDigital is structured specifically around reliability, accountability, and operational maturity. Our focus is not just keeping websites online — it’s ensuring: - Clear ownership of incidents - Proactive monitoring and response - Realistic, enforceable SLAs - Transparent communication during issues - Long-term stability, not short-term fixes This is how SLA breaches are avoided — not just reacted to. ##### [Replacing an Agency](/services/website-vendor-replacement-and-transition-services) After an SLA Breach When an SLA breach occurs, many organisations choose to: - Reassess their digital support model - Move away from reactive agencies - Seek a partner experienced in enterprise-grade operations We regularly support organisations transitioning after a breached website or application SLA, ensuring continuity, stability, and confidence moving forward. ##### Who This Page Is For This is relevant if: - Your website or app SLA has been breached - You’re losing confidence in your current agency - Your organisation requires uptime and reliability - You manage public-facing or mission-critical platforms - You need a partner who understands SLA accountability If SLA commitments matter to your organisation, they should matter to your digital partner. ##### Common Questions **Is an SLA breach always grounds to change agencies?** Not always — but repeated or poorly handled breaches are a serious warning sign. **Can SLA issues be fixed without changing vendors?** Sometimes. Often the underlying operational model is the real issue. **How quickly can stability be restored after a breach?** That depends on visibility, monitoring, and ownership — all areas where many agencies fall short. **Do you take over existing websites and applications?** Yes. We regularly inherit platforms where SLAs were previously breached. ##### Next Step If your website or application SLA has been breached, the most important question is: Will it happen again? The answer depends on who is responsible moving forward. --- ### Website Support SLAs for Enterprise & Government URL: https://undigital.com.au/services/website-support-slas-for-enterprise-and-government **Guaranteed response times, uptime reporting, continuous monitoring, and predictable support built for high-risk organisations. We provide Website Support SLAs for [Enterprise & Government](/specialisations) to [Sydney, Brisbane and Sunshine Coast](/contact).** ##### Why SLAs Matter When your website is mission-critical, “good enough” support isn’t enough. Large organisations need predictable outcomes, measured performance, and full accountability. That’s why UnDigital builds SLAs that are clear, enforceable, and aligned with enterprise expectations. No vague promises. No finger-pointing. Just measurable reliability and rapid response. ##### The Risks of Poor Support - Website downtime that impacts operations - Missed security updates leaving vulnerabilities exposed - Delays in critical fixes causing financial or reputational loss - Frustrated internal teams scrambling to cover gaps - Enterprise and government teams can’t afford this. Our SLAs eliminate these headaches. ##### Our [SLA Services](/services) Include - **Guaranteed response times:** Tiered response based on issue severity - **Uptime and security monitoring:** 24/7 tracking with proactive alerts - **Incident management: **Immediate triage, escalation, and resolution - **Monthly reporting: **Metrics and insights for board and executive review - **Retainer-based support: **Flexible coverage that scales with your needs - Security updates and patching > “UnDigital’s SLA gave us peace of mind. We know issues are handled quickly, and reporting keeps everyone accountable.” - IT Manager, NSW Government ##### **Process** - Assess your current environment - Define SLA tiers with measurable targets - Integrate monitoring and ticketing systems - Deliver monthly reports with actionable insights - Continuous optimisation based on scans and metrics ##### FAQs **Q: Can SLAs cover both security and website operational issues?** A: Yes. Our SLAs are comprehensive and cover uptime, technical issues, and security patching. **Q: Do you provide 24/7 coverage?** A: Absolutely. Critical incidents are prioritised around the clock. --- ### Website Uptime Monitoring That Actually Detects Outages URL: https://undigital.com.au/services/website-uptime-monitoring-service **This page explains how website uptime monitoring actually works, which checks detect real outages and which ones miss them, and how availability is measured and enforced against an SLA. It is written for IT managers, digital leads and agency owners responsible for a website that generates revenue or leads.** #### A server being up and a website working are different things Most monitoring tools answer one question: did an HTTP request to the home page return a 200 in under thirty seconds? That question has a green answer in a surprising number of genuine outages. A WordPress site with a fatal error in a plugin can return 200 with a blank body. A Silverstripe site whose database connection pool is exhausted can serve cached pages from Cloudflare while every form submission fails. A Magento store can render the catalogue perfectly while the payment gateway integration times out at checkout. A Drupal site can be fully available to anonymous visitors and completely broken for logged-in editors. In every case the status page stays green, and the first person to notice is a customer. Availability monitoring that is worth paying for tests the things the business actually depends on: that the page renders the content it is supposed to render, that a form posts and writes a record, that the checkout reaches the confirmation step, that the API the mobile app calls returns valid JSON. Anything less is a server ping wearing a marketing name. #### Check types and what each one can and cannot detect A monitoring configuration is a set of assertions. Each type catches a different failure class, and the gaps between them are where outages hide. | Check type | What it does | Detects | Misses | | --- | --- | --- | --- | | HTTP status | Requests a URL and asserts a 2xx or 3xx response | Server down, 500 errors, DNS failure, connection refused, timeouts | White screens, wrong content, broken forms, degraded but responding services | | Keyword assertion | Asserts a known string is present in the response body, or that an error string is absent | Blank renders, PHP fatal errors printed to the page, maintenance mode left on, defaced or wrong content | Failures behind a login, anything not on the tested page | | Transaction (browser) check | Drives a headless browser through a multi-step journey: search, add to cart, submit an enquiry, log in | Broken checkout, failing form handlers, JavaScript errors, broken session handling, third-party script failures | Backend jobs that run outside the request cycle | | API endpoint check | Calls an endpoint and asserts status code, response schema and latency | Broken integrations, CRM sync failures, headless frontends served by a dead backend | Frontend rendering problems | | TLS certificate check | Inspects certificate expiry, chain validity and hostname match | Expiring certificates, broken intermediate chains, mismatched SANs after a domain change | Application faults of any kind | | Heartbeat / dead man's switch | Waits for a job to check in on a schedule and alerts when it does not | Failed cron, stalled queue workers, backups that stopped running | Jobs that run but produce wrong output | A reasonable baseline for a lead-generating corporate site is: HTTP plus keyword on the home page and two or three key landing pages, a transaction check on the primary enquiry form, an API check on the CRM integration, certificate monitoring on every hostname, and heartbeats on cron and backups. For ecommerce, add a full checkout transaction check and a search results assertion. #### Interval, multi-location confirmation and false alarms Check interval sets the ceiling on how fast you can possibly know. A five minute interval means a mean detection delay of around two and a half minutes and a worst case of five, before anyone has even looked at the alert. One minute intervals are the practical standard for revenue-critical sites. Thirty second intervals are worth it for checkout paths during peak trading. The counterweight is noise. A single failed check from a single probe should never page a human. The pattern that works is confirmation: when a probe in Sydney sees a failure, probes in Melbourne, Singapore and somewhere further afield re-test immediately, and the incident only opens if two or more independent locations agree. That single rule removes most false alarms, because the usual causes are local to the probe. Common sources of false positives worth designing out: - A WAF or bot management rule challenging the monitoring probe. Allow-list probe IP ranges or use a signed header, and review it after every firewall change. - Rate limiting triggered by the monitoring itself when intervals are aggressive and check counts are high. - Transient DNS resolution failures at the probe's resolver rather than at your authoritative nameservers. - Transaction checks that break because a developer renamed a CSS selector, not because anything is down. Assert on stable attributes, not on styling hooks. - Timeout thresholds set so tight that a slow but working page counts as an outage. Separate "down" from "degraded" and alert on them differently. A monitoring system that cries wolf gets muted, and a muted system is worse than no system because it creates the belief that someone is watching. #### The failures that break silently The outages that do real damage are frequently the ones nobody notices for days, because the website looks perfectly fine the whole time. These need explicit instrumentation. - **Cron and scheduled tasks.** Silverstripe queued jobs, WordPress WP-Cron, Drupal cron and Laravel schedulers all fail quietly. A heartbeat per critical job, with an expected interval, turns silence into an alert. - **Queue workers.** A worker process that dies leaves jobs accumulating. Monitor queue depth and oldest-job age, not just whether the process exists. - **Mail delivery.** Enquiry forms that appear to submit successfully while SMTP authentication fails, or while the sending domain's SPF, DKIM and DMARC alignment breaks after a DNS change, are the single most expensive silent failure for lead-generating sites. Monitor send success rate and bounce rate, not just the form's thank-you page. - **Search index.** Elasticsearch, Solr or a hosted search service that stops indexing leaves a site returning zero results for everything. Assert that a known query returns a known result. - **Cache and CDN behaviour.** A cache that stops being written turns into a full-price origin load test. Monitor hit ratio and origin request volume. - **Disk, inodes and database growth.** Log files and session tables fill volumes. Alert at 75 percent, not at 95 percent. - **Backups.** A backup job that has been failing for six weeks is only discovered when it is needed. Verify that the artefact exists, that its size is within tolerance, and periodically that it restores. #### Certificates, DNS and domain renewal Certificate expiry is the most avoidable outage there is, and it still happens constantly, usually on a hostname nobody remembered: a legacy redirect domain, a staging environment, a mail subdomain, an API host. Monitor every certificate on every hostname, alert at 30, 14 and 7 days, and alert separately if an automated renewal such as Let's Encrypt has not rotated the certificate within its expected window. DNS deserves the same treatment. Monitor that authoritative nameservers answer, that critical records resolve to the expected values, and that the domain registration itself is not approaching expiry. Registrar renewal notices go to an inbox that belonged to someone who left. Records get changed during unrelated projects and nobody re-checks the mail records. Watch the values, not just the resolution. #### Synthetic checks versus real user monitoring Synthetic monitoring runs scripted checks from known locations on a schedule. Real user monitoring (RUM) reports what actual visitors experienced, including Core Web Vitals, JavaScript errors and failed requests from their browsers. | Synthetic monitoring | Real user monitoring | | --- | --- | | Runs when | Always, including overnight and on low-traffic pages | | Best at | Detecting outages, proving availability for SLA reporting | | Catches | Hard failures on the paths you chose to script | | Weakness | Blind to anything not scripted | You need both. Synthetic checks are what an SLA is measured against, because they are consistent and independent of traffic. RUM is what tells you the enquiry form has been failing for Safari users on iOS for a week while every synthetic check stayed green. #### Alert routing and the on-call chain behind the alert Monitoring is the cheap part. The expensive part is a human who is awake, contactable, authorised and technically capable of fixing the specific application that has broken. This is where most arrangements fall apart: the hosting provider's on-call engineer can restart a server but will not debug a plugin conflict, and the agency that built the site does not monitor anything and reads email at 9am. A functioning escalation design specifies severity levels with different routing, a primary and secondary on-call engineer, a maximum acknowledgement time before escalation, and a defined authority to act without waiting for client sign-off during a Severity 1. It also specifies who talks to the business while the engineer works, because an incident with no communication feels twice as long. Our guidance on [what to do in the first hour of an outage](/services/urgent-website-support-first-hour?stage=Stage) covers the sequence in detail, and [break/fix and emergency support](/services/break-fix-and-emergency-website-support?stage=Stage) covers the arrangement for organisations without an existing retainer. #### How uptime is measured and reported against an SLA An uptime percentage is meaningless until you know what was measured, from where, at what interval, and what was excluded. Before signing anything, get those four answers in writing. | Target | Allowed downtime per month | Allowed downtime per year | Typically appropriate for | | --- | --- | --- | --- | | 99.5% | 3h 39m | 1d 19h 48m | Brochure and internal sites | | 99.9% | 43m 12s | 8h 46m | Corporate and government sites, lead generation | | 99.95% | 21m 36s | 4h 23m | High-traffic content and transactional sites | | 99.99% | 4m 19s | 52m 36s | Ecommerce and revenue-critical applications | Note what 99.99 percent implies. Four minutes a month is less than the time it takes a human to read an alert and log in, which means the target is only credible with redundancy that fails over automatically. Be suspicious of any provider offering it on a single server. Also check the exclusions. Scheduled maintenance windows, third-party provider failures, DDoS events and customer-caused incidents are commonly excluded, and some contracts exclude so much that the number is unfalsifiable. Reporting should come from an independent measurement source, list every incident with start time, end time, cause and remediation, and be issued monthly without being requested. If a target has been missed, our page on [what to do after an SLA breach](/services/website-sla-breach-what-to-do-next?stage=Stage) sets out the practical options. #### Monitoring for infrastructure you already own Plenty of organisations are contractually or architecturally committed to their own AWS, Azure or Google Cloud account, or to a hosting provider they cannot leave this financial year. That does not prevent an independent monitoring and response arrangement. In a management-only engagement, the monitoring stack, alerting, escalation and remediation run against infrastructure you continue to own and pay for directly. CloudWatch and Azure Monitor cover the infrastructure layer well and the application layer poorly, so the value added is application-level assertions, heartbeats on background processing, an on-call chain that includes developers who know the CMS, and consolidated reporting across your cloud provider, your CDN and your application. Edge-layer telemetry matters here too, and [Cloudflare for enterprise websites](/services/benefits-of-cloudflare-for-enterprise-websites?stage=Stage) covers what the edge can tell you before a request ever reaches origin. Availability monitoring also sits alongside [CVE scanning and vulnerability monitoring](/cve-scanning-and-vulnerability-monitoring?stage=Stage), because a compromised site and a down site frequently arrive on the same night. #### Frequently Asked Questions ##### What is website uptime monitoring? Website uptime monitoring is the automated, repeated testing of a website from external locations to detect when it stops working. Effective monitoring goes beyond checking for an HTTP 200 response and includes content assertions, scripted user journeys, API checks, certificate expiry and heartbeats on background jobs. The purpose is to detect a failure before customers do and to produce an independent record of availability. ##### How often should a website be checked? One minute intervals are the practical standard for websites that generate revenue or leads, with thirty second intervals on checkout and payment paths during peak trading. Five minute intervals are acceptable for low-stakes sites but add up to five minutes of detection delay before anyone is notified. Whatever the interval, failures should be confirmed from at least two independent geographic locations before an incident is raised. ##### Why did my monitoring tool say the site was up when it was clearly broken? Because it was almost certainly only checking the HTTP status code of one URL. A site can return 200 while rendering a blank page, serving cached content from a CDN with a dead origin, failing every form submission, or breaking at checkout. Keyword assertions, transaction checks and API checks are what close that gap. ##### What does 99.9% uptime actually allow? A 99.9 percent target allows 43 minutes and 12 seconds of downtime per month, or roughly 8 hours 46 minutes per year. 99.99 percent allows 4 minutes 19 seconds per month, which cannot realistically be met without automatic failover across redundant infrastructure. Always check what the contract excludes from the calculation, because scheduled maintenance and third-party failures are commonly carved out. ##### Can monitoring be provided if we host on our own AWS or Azure account? Yes. A management-only arrangement applies monitoring, alerting, escalation and remediation to infrastructure you continue to own and pay for directly. This suits organisations with cloud commitments, internal security requirements or procurement rules that prevent moving hosting. ##### What is the difference between monitoring and an SLA? Monitoring detects a problem and sends an alert. An SLA is the contractual commitment that a named party will acknowledge that alert within a defined time, begin work within a defined time, and be accountable if they do not. Monitoring without a response obligation just documents your outages more precisely. #### Managed uptime monitoring and response from UnDigital An alert is only worth as much as the person obliged to answer it. UnDigital operates monitoring and the engineering team that acts on it, which means the same organisation that detects a fatal error in a Silverstripe module or a failing WordPress cron is also the one that fixes it, with no gap between the infrastructure vendor and the development vendor for the problem to fall into. Monitoring is configured per site rather than from a template: the pages, journeys, endpoints, jobs and certificates that matter to your business, with response times and escalation paths set out in a [website support SLA](/services/website-support-slas-for-enterprise-and-government?stage=Stage) and reported monthly. It is available as part of [managed hosting](/managed-hosting?stage=Stage) or as a management-only engagement on infrastructure you already own. Every engagement starts with an audit of what is currently being monitored, which almost always finds something important that is not. --- ### Website Vendor Replacement & Transition Services URL: https://undigital.com.au/services/website-vendor-replacement-and-transition-services **We take over [complex CMS environments](/technology), improve reliability, fix inherited issues, and give you stable long-term operations. We provide [Website Vendor Replacement & Transition Services](/services) to [Sydney, Brisbane and Sunshine Coast](/contact).** ##### Switching Vendors Doesn’t Have to Be Painful Many [enterprises](/specialisations) inherit messy websites: outdated CMS, broken integrations, security risks. Internal teams are stuck. UnDigital makes vendor transition seamless with no downtime, full documentation, and immediate improvements. ##### What’s Included - CMS & plugin audit - Security & performance review - Bug fixing and backlog cleanup - Full handover documentation - SLA-aligned support from day one > “We were losing months of productivity before UnDigital took over. Transition was smooth and immediate.” – Marketing Director, Drinkwise ##### Transition Process - Discovery & audit of current site - Migration plan & risk assessment - Backlog remediation & optimisation - Knowledge transfer & documentation - SLA onboarding & ongoing support --- ### White-Label Website Hosting & SLAs for Australian Agencies URL: https://undigital.com.au/services/white-label-hosting-for-australian-agencies **This page is for agency owners and account directors who win website retainers their team cannot technically service: it explains what clients actually expect from a managed website arrangement, why uptime and response commitments are hard to underwrite without infrastructure, and how white-label and referral fulfilment models let an agency sell those commitments safely.** #### The retainer problem: winning work you cannot technically service Most agencies are very good at one part of the lifecycle. You research, position, design, write, build the campaign, launch the site. Then the client asks the reasonable follow-up question: who looks after this now? At that point three things usually happen. The agency says yes because the retainer is worth more than the project, then quietly discovers it has committed to CMS core upgrades, PHP version migrations, TLS renewals, WAF tuning and after-hours incident response. Or the agency says no, and the client hands the ongoing relationship to a hosting company that will not touch the application, which means the agency loses visibility and eventually loses the account. Or the agency subcontracts to whoever built the site last, with no contract, no defined response times and no idea who is on call at 11pm on a Saturday. None of these are failures of talent. Hosting is a different discipline with a different cost structure. Running production infrastructure means monitoring, patching, backup verification, incident escalation and someone awake when a site goes down. That is a permanent operational overhead, and it does not pay for itself across a handful of client sites. #### What clients ask for that most agencies cannot sign The gap shows up in procurement documents and in the fine print of retainer agreements. Enterprise and government buyers, and increasingly mid-market ones, ask for commitments that are meaningless unless somebody controls the stack: - A stated uptime percentage, measured externally, with service credits if it is missed - Response and resolution targets by severity, including a P1 path that runs outside business hours - Backup frequency, retention period and a tested restore procedure with a stated recovery time objective - Data residency in Australia, and named sub-processors - Patching cadence for the CMS, its modules and the underlying operating system - Vulnerability scanning, WAF and DDoS protection, and evidence for annual penetration tests - Cyber liability insurance at a stated cover level, and named-insured provisions - An exit clause requiring a full data and configuration handover within a set number of days An agency without infrastructure capability can write those clauses into a proposal, but it cannot honour them. Signing a document you cannot operationally satisfy is a commercial risk, not a sales win. A properly constructed [website support SLA for enterprise and government](/services/website-support-slas-for-enterprise-and-government?stage=Stage) is an operational commitment backed by monitoring and rostering, not a marketing paragraph. #### Uptime commitments, response times and why they are hard to underwrite ##### The arithmetic of a percentage Uptime figures look similar on a page and are wildly different in practice. The difference between 99.5% and 99.99% is the difference between a quiet afternoon of outage and a coffee break. | Uptime target | Allowed downtime per month | Allowed downtime per year | What it realistically requires | | --- | --- | --- | --- | | 99.5% | 3 hours 39 minutes | 43.8 hours | Single server, business-hours response | | 99.9% | 43 minutes | 8.8 hours | Monitoring at 1 minute intervals, on-call roster, tested restores | | 99.95% | 21 minutes | 4.4 hours | Redundant application layer, CDN failover, staged deployments | | 99.99% | 4 minutes | 52 minutes | Multi-AZ architecture, automated failover, zero-downtime deploys | Note that maintenance windows, DNS propagation and third-party outages all have to be defined as in or out of scope, otherwise the number is unenforceable in either direction. ##### Response is not resolution The most common drafting error in agency retainers is promising a resolution time. Resolution depends on the fault. A misconfigured redirect is fifteen minutes; a corrupted database on a site with no verified backup is a very different afternoon. What can be committed to is time to acknowledge, time to triage, time to first meaningful update and update frequency thereafter. Severity definitions need to be written against business impact, not technical symptom: a checkout that fails for 8% of card types is a P1 even though the site is up. #### Out-of-hours cover, escalation and on-call reality Twenty-four hour cover is a rostering problem before it is a technical one. To genuinely answer a P1 at 2am you need more than one person who can log into production, documented runbooks so the person on call is not reverse-engineering a build they have never seen, alerting that pages a human rather than sending an email nobody reads, and a defined escalation path when the first responder cannot resolve it within a set window. Agencies rarely have the headcount to sustain that across a small portfolio, and the informal version, where the lead developer's mobile number is the escalation path, fails the first time that person is on annual leave. It also fails at review time, when the client asks for the incident log. Unplanned faults still need a home, which is why [break/fix and emergency website support](/services/break-fix-and-emergency-website-support?stage=Stage) has to be scoped explicitly rather than assumed to sit inside a monthly hours bucket. #### White-label versus referral: how each model works ##### White-label You buy hosting, monitoring, patching and SLA cover at a wholesale rate and resell it under your own brand at your own margin. The client contracts with you, is invoiced by you, and raises tickets through your channel. The fulfilment partner is invisible and works under your name. You keep the account, the relationship and the pricing control, and you take on the commercial relationship with the client for that line item. ##### Referral You introduce the client, the fulfilment partner contracts and invoices directly, and you receive a recurring share of the revenue for as long as the client stays. You carry no delivery obligation and no invoicing overhead, but you also do not set the price and the technical relationship sits with the partner. ##### Commercial structures compared | Attribute | White-label | Referral | | --- | --- | --- | | Who holds the client contract | The agency | The fulfilment partner | | Who invoices the client | The agency | The fulfilment partner | | Who sets the retail price | The agency | The fulfilment partner | | Agency revenue | Margin on wholesale rate | Recurring revenue share | | Brand shown to the client | The agency's | The partner's | | Support channel | Agency-branded, partner-fulfilled | Direct to partner | | Agency admin overhead | Moderate: billing and first-line triage | Minimal | | Best suited to | Agencies protecting an account and wanting margin | Agencies who want the client looked after without owning the line | #### What sits with the agency and what sits with the fulfilment partner The arrangement only works if the boundary is written down before the first ticket, not negotiated during an incident. | Responsibility | Typically the agency | Typically the fulfilment partner | | --- | --- | --- | | Client relationship and strategy | Yes | No | | Design, content and campaign work | Yes | No | | Server provisioning, scaling and OS patching | No | Yes | | CMS core, module and dependency updates | No | Yes | | Backups, restore testing and DR | No | Yes | | WAF, CDN, DNS and certificate management | No | Yes | | Uptime and P1 incident response | No | Yes | | Feature development and enhancements | Shared, scoped per request | Shared, scoped per request | | Security questionnaires and audit evidence | Fronts the client | Supplies the evidence | #### Migrating an existing client portfolio without downtime Most agencies coming into a program like this arrive with an inherited mess: a few sites on a reseller account, one on a client's own AWS bill nobody has audited, one on a platform the original developer chose in 2018. Moving them is routine, but only in a defined order. - Audit each site: platform and version, PHP or Node runtime, database engine, cron jobs, third-party integrations, mail sending, DNS registrar and current TTL values - Identify the risks before the move: unsupported CMS versions, hardcoded absolute URLs, licence keys tied to an IP, or file storage outside the web root - Build the target environment and deploy a full copy, then test against a hosts-file override so real users are unaffected - Lower DNS TTLs 24 to 48 hours ahead of the cutover - Cut over during a low-traffic window with a final content and database sync, then verify SSL, redirects, forms, payment callbacks and analytics tracking - Keep the origin environment running read-only for a defined rollback period Where the incumbent is uncooperative, credentials are incomplete or the relationship has already broken down, the sequence needs more care. That situation is common enough to be its own discipline, covered in [website migration to a new vendor](/services/website-migration-to-a-new-vendor?stage=Stage). #### Reporting your client sees, and reporting you see Retainers are renewed on evidence. A monthly report that reads "maintenance performed" invites the client to question the line item. A useful client-facing report states measured uptime against the target, the number of incidents by severity with time to acknowledge and resolve, patches applied with version numbers, backup success rate and the date of the last verified restore, blocked malicious requests, and core performance metrics. Behind that, the agency needs its own view: which sites are approaching end-of-life on their CMS or runtime, which have accumulated overdue module updates, where the resource ceiling is close, and which clients are consuming disproportionate support hours. That internal view is what turns a hosting line item into an upgrade conversation. It is also the raw material for [website governance, compliance and risk management](/services/website-governance-compliance-and-risk-management?stage=Stage), which is increasingly what larger clients are actually buying. #### Security, compliance and government client requirements Once an agency's client list includes a council, a department, a listed company or anyone with a procurement function, security questions arrive in writing. Expect requests for Australian data residency, MFA on all administrative access, a documented patching SLA, evidence of vulnerability scanning, Content Security Policy headers, incident notification timeframes under the Notifiable Data Breaches scheme, and remediation of findings from an annual penetration test. These are answerable, but only by whoever holds the infrastructure. An agency reselling under a white-label arrangement should be able to request the underlying evidence rather than compose reassuring prose, which means the fulfilment partner needs continuous [website security management and monitoring](/services/website-security-management-and-monitoring?stage=Stage) in place already rather than assembled on request. #### How to evaluate a fulfilment partner before you put your brand on it You are lending your reputation to someone else's operations. Ask for specifics, and be suspicious of answers that avoid numbers: - Where is the infrastructure physically located, and who is the underlying provider? - What is the monitoring interval, what triggers a page, and who receives it at 3am? - How often are backups taken, how long are they retained, and when was a restore last tested end to end? - Which platforms do they genuinely operate, and can they perform major version upgrades rather than only patch releases? - Do they have developers, or only systems administrators? An infrastructure-only partner will not fix an application fault. - What are the severity definitions and response targets, in writing? - Will they attend a client call under your brand if you need them to, and will they stay silent about their own? - What is the exit process, and who owns the client relationship if the partnership ends? - What is the minimum commitment, and does the rate change if you only ever send two sites? #### Frequently asked questions ##### What is white-label website hosting for agencies? White-label website hosting is an arrangement where a specialist provider supplies infrastructure, monitoring, patching and support under another agency's brand. The agency buys at a wholesale rate, sets its own retail price, holds the client contract and invoices directly. The fulfilment partner does the technical work and does not appear to the end client. ##### Can a marketing or branding agency offer an uptime SLA without hosting anything itself? Yes, provided the commitment is backed by a fulfilment partner who operates the infrastructure and contractually offers the agency the same or better terms. The agency should never promise a client a target it has not secured on the back end, including response times, backup frequency and out-of-hours cover. The safe approach is to mirror the partner's SLA rather than write an aspirational one. ##### What is the difference between the white-label and referral models? Under white-label the agency owns the contract, the invoice and the pricing, and earns the margin between wholesale and retail. Under referral the fulfilment partner contracts and invoices the client directly and pays the agency a recurring share of the revenue. White-label gives more control and more margin; referral gives less administration and no delivery obligation. ##### How many websites do we need before a white-label arrangement makes sense? There is no technical minimum. Some agencies start with a single high-value client whose procurement requirements they cannot otherwise meet, then move the rest of the portfolio over time. The commercial case usually appears at the first site, because the alternative is either declining the retainer or absorbing an operational cost that has no ceiling. ##### What happens to our clients if the partnership ends? Under a properly written agreement the agency retains the client relationship and the partner provides a full handover: server configuration, database dumps, file archives, DNS records, certificates and documentation within a defined period. Confirm this before signing rather than after. The absence of a clear exit clause is the strongest signal to walk away. ##### Does the client ever find out a third party is involved? Under a white-label arrangement, only if the agency chooses to disclose it, and some government and enterprise procurement processes require sub-processors to be named. The fulfilment partner works under the agency's brand in tickets, reports and, where needed, on client calls. Where disclosure is required, having a named Australian partner with documented controls is usually an advantage rather than a problem. #### The UnDigital Agency Hosting Program UnDigital runs managed hosting and website management for enterprise, government and ecommerce clients, and provides the same capability to agencies under their own brand. We are both the infrastructure and the development capability, which is the point: when an application fault takes a site down, there is no argument about whether it is a server problem or a code problem. The [Agency Hosting Program](/agency-hosting?stage=Stage) operates on the two models above, white-label or referral, with no minimum number of sites and no requirement that your clients sit on any particular platform. We handle provisioning, monitoring, patching, backups, WAF and CDN configuration, incident response and reporting. You keep the client, the strategy and the creative work. Wholesale rates are not published, because they depend on the architecture each site actually needs. The starting point is a call and an audit of what you currently have running. --- ### Why Your Website Should Have MFA (Multi-Factor Authentication) URL: https://undigital.com.au/services/why-your-website-should-have-mfa **Strengthen login security, reduce account compromise, and demonstrate enterprise-level risk management with two-factor authentication (2FA) for your digital platforms. We provide [MFA and Security Services](/services) to [Sydney, Brisbane and Sunshine Coast](/contact).** ##### What Is MFA (Multi-Factor Authentication)? Multi-factor authentication, often called MFA, or two-factor authentication (2FA), adds an additional layer of security to website logins beyond just a password. Instead of relying solely on something a user knows (their password), MFA requires something they have or are, such as: - A one-time code sent to a device - An authenticator app - A hardware security key - Biometric verification This additional step drastically reduces the risk of account compromise. ##### Why MFA Matters for Your Website Even complex, unique passwords are vulnerable to: - Credential theft - Phishing attacks - Brute-force attacks - Account takeover by malicious actors Enabling MFA or 2FA for your website prevents most of these attacks before they reach your servers. For enterprise, government, and high-traffic websites, MFA isn’t optional — it’s a critical security control. ##### Key Benefits of Implementing MFA / 2FA ###### 1. Reduce Account Compromise Risk - Protect administrative logins - Secure user accounts and portals - Stop stolen credentials from causing damage ###### 2. Demonstrate Compliance and Governance - Many audits and frameworks now recommend MFA - Supports regulatory requirements - Shows stakeholders proactive risk management ###### 3. Protect Sensitive Data - Prevent exposure of private data - Reduce risk to both the organisation and users - Enhance trust for customers and internal teams ###### 4. Mitigate Credential-Based Attacks - Stop phishing attempts from succeeding - Reduce brute-force or password spray risks - Protect against reused credentials across multiple sites ###### 5. Strengthen Overall [Security Posture](/services/improving-the-security-posture-of-your-digital-platforms) - MFA or 2FA is part of a layered defence strategy - Integrates with broader security tools, monitoring, and SLAs - Supports enterprise risk management goals ##### Common Myths About MFA / 2FA **“MFA is too complex for users.”** Most solutions are user-friendly and supported across desktop and mobile. **“2FA slows down login.”** The small additional step is negligible compared to the risk of account compromise. **“Passwords alone are enough.”** Even strong passwords can be stolen or phished — MFA significantly increases protection. **“MFA is only for administrators.”** While admins are high-risk, enterprise users benefit from MFA across portals, dashboards, and sensitive systems. ##### Why Enterprises Choose UnDigital for MFA We don’t just enable MFA. We design it into your digital environment so it: - Protects your most critical systems - Integrates without disrupting workflows - Supports compliance and governance - Reduces administrative overhead We’ve implemented MFA / 2FA across enterprise websites, government platforms, and high-traffic portals, helping organisations reduce risk and demonstrate digital accountability. ##### Who Should Implement MFA / 2FA MFA is essential for: - Administrative and CMS logins - Enterprise web applications and intranets - Customer portals with sensitive data - Government or regulated websites - High-traffic, high-risk platforms If your organisation values security, MFA isn’t optional — it’s foundational. ##### FAQs **Q: What’s the difference between MFA and 2FA?** A: 2FA is a form of MFA that specifically uses two factors. MFA can use two or more, depending on risk. **Q: Can MFA prevent all cyber attacks?** A: No security measure is perfect. MFA dramatically reduces credential-related risk but should be part of a layered security approach. **Q: Will MFA impact user experience?** A: Modern MFA/2FA solutions are fast and user-friendly. The slight extra step is worth the security gain. **Q: Is MFA required for compliance?** A: Increasingly, yes. Many regulatory and security frameworks expect MFA for administrative and sensitive access. ##### Next Step Multi-factor authentication (MFA) and two-factor authentication (2FA) are essential for protecting your website, users, and business-critical systems. If you’re researching MFA, it usually means you’re thinking about: - Reducing risk and account compromise - Improving governance and compliance - Strengthening your organisation’s overall [digital security posture](/services/improving-the-security-posture-of-your-digital-platforms) --- ## Contact Information - **Website:** https://undigital.com.au - **Phone:** 0406 906 973 - **Email:** Available via contact form at https://undigital.com.au/contact - **Locations:** Sydney, Sunshine Coast (Australia), Ho Chi Minh City (Vietnam) --- ## Sitemap - Homepage: https://undigital.com.au - Our Story: https://undigital.com.au/our-story - Services: https://undigital.com.au/services - Specialisations: https://undigital.com.au/specialisations - Technology: https://undigital.com.au/technology - Work/Results: https://undigital.com.au/work - Press: https://undigital.com.au/press - Contact: https://undigital.com.au/contact - Managed Hosting for Enterprise Websites: https://undigital.com.au/managed-hosting - Agency Hosting Program (White-Label Hosting & SLAs): https://undigital.com.au/agency-hosting - WordPress Hosting: https://undigital.com.au/managed-hosting/wordpress-hosting - WordPress Website Management: https://undigital.com.au/managed-hosting/wordpress-website-management - Silverstripe Hosting: https://undigital.com.au/managed-hosting/silverstripe-hosting - Silverstripe Website Management: https://undigital.com.au/managed-hosting/silverstripe-website-management - Drupal Hosting: https://undigital.com.au/managed-hosting/drupal-hosting - Drupal Website Management: https://undigital.com.au/managed-hosting/drupal-website-management - Custom & Headless Hosting (Storyblok, Sanity, Craft CMS, Statamic, Next.js): https://undigital.com.au/contact - Silverstripe Hosting Agency: https://undigital.com.au/silverstripe-hosting-and-maintenance-partner-agency - Magento Hosting Agency: https://undigital.com.au/magento-hosting-and-maintenance-agency - HubSpot Agency: https://undigital.com.au/hubspot-agency-partner - Website Support SLAs: https://undigital.com.au/services/website-support-slas-for-enterprise-and-government - CVE Scanning & Vulnerability Monitoring: https://undigital.com.au/cve-scanning-and-vulnerability-monitoring - Website Uptime Monitoring: https://undigital.com.au/website-uptime-monitoring - Content Security Policy: https://undigital.com.au/services/content-security-policy-csp-for-enterprise-websites - Penetration Test Prep: https://undigital.com.au/services/preparing-for-a-penetration-test - Cloudflare Enterprise: https://undigital.com.au/services/benefits-of-cloudflare-for-enterprise-websites - Break/Fix Support: https://undigital.com.au/services/break-fix-and-emergency-website-support - SilverStripe 4 to 5 Upgrade: https://undigital.com.au/services/upgrading-from-silverstripe-4-to-silverstripe-5 - SilverStripe 5 to 6 Upgrade: https://undigital.com.au/services/upgrading-from-silverstripe-5-to-silverstripe-6 - Integrations & Automation: https://undigital.com.au/integrations-and-business-automation