Plan updates. Verify function. Keep operations running.
An update is complete when the environment still works afterward. We plan patching, upgrades, and lifecycle changes around your actual systems, dependencies, and operational requirements.
Nine phases from inventory to the next lifecycle milestone.
The depth of testing follows the risk. Each phase has a defined outcome, owner, and approval point. Open the steps to explore the technical details.
01
Inventory the environment
Record operating systems, applications, runtimes, databases, drivers, firmware, networks, reverse proxies, and containers. Include clusters, third-party components, and custom software. Agree on critical services, owners, and operating windows.
Outcome: A verified inventory of versions, responsibilities, and business-critical functions.
02
Understand dependencies
Document how business applications connect to .NET, Java, PHP, Visual C++, ODBC/OLE DB, and databases. Consider TLS, SMB, authentication, security policies, and container networks. Check vendor compatibility and the required update order.
Outcome: A dependency map that explains the update order and application tests.
03
Check lifecycle and vendor upgrade paths
Compare current and target versions with support status, release notes, known issues, breaking changes, and deprecations. Resolve required intermediate versions and migrations before maintenance. Record EOL dates with a source and review date.
Outcome: An evidence-based upgrade path with required stops and unresolved compatibility questions.
04
Assess risk and classify the update
Distinguish routine, security, feature, runtime, and firmware updates from major releases and lifecycle migrations. Exposure, criticality, impact, testability, and recovery options determine priority and approval requirements.
Outcome: A documented risk assessment with approval and stop criteria.
05
Define tests and a pilot
Use staging, a test VM, pilot devices, a replica, or an appropriate cluster node. Test real business tasks, authentication, integrations, scheduled jobs, and load. Name technical reviewers and business approvers separately.
Outcome: Defined test cases, a limited pilot, and named acceptance owners.
06
Prepare rollback and recovery
Plan consistent backups, a restore test, configuration recovery, and service restart. A snapshot alone is not a backup. Schema changes may prevent a simple downgrade. Define the recovery time budget, acceptable data loss, and restore or roll-forward decision in advance.
Outcome: An executable recovery plan with a tested backup and decision points.
07
Coordinate and execute the rollout
Agree on maintenance windows, groups, sequence, reboots, communication, and escalation. Approve wider deployment after the pilot passes. Check each stage and stop on agreed failure conditions. Account for cluster availability, storage, and database dependencies.
Outcome: A phased rollout with documented approvals and clear ownership.
08
Verify application function and operations
Compare services, logs, monitoring, user workflows, and performance with the baseline. Test business applications, integrations, background jobs, backups, and replication. A successful installation message is not sufficient for acceptance.
Outcome: Technical and business acceptance backed by recorded test results.
09
Document and continue lifecycle management
Record versions, exceptions, and remaining risks. Assign upcoming EOL dates, major upgrades, deprecations, and technical debt to an owner. Monitor vendor announcements and schedule changes before features are removed.
Outcome: An up-to-date operational record and a prioritized plan for the next cycle.
Different updates need different approval paths.
Assess security risk and operational risk together. Automation makes sense when boundaries, tests, and recovery are defined.
| Update class | Approach | Approval point |
|---|---|---|
| Routine / low risk | Prompt or automated release under defined rules | Pilot, monitoring, and documented exceptions |
| Security / critical vulnerability | Assess exposure, prioritize, use emergency maintenance if needed | Accountable decision with focused testing and recovery |
| Major / runtime / firmware | Review vendor paths, dependencies, and test migration separately | Technical and business approval before broad deployment |
| EOL / deprecation | Test the replacement, plan migration and retirement | Acceptance before support ends or the old feature is removed |
There is no universal waiting period for major releases or automatic immediate approval for security patches. Impact, attack surface, and recoverability determine the appropriate path.
Dependencies determine what needs testing.
These scenarios illustrate the method. Product versions and specific vendor paths are checked afresh for each project.
Windows and business software
After a patch, we check Windows together with the business application, Visual C++ or .NET runtime, ODBC/OLE DB drivers, TLS, and authentication. A test case follows a real workflow, such as signing in, retrieving data, and printing.
Linux and the web stack
A PHP upgrade requires extensions, Composer dependencies, the web server, reverse proxy, database drivers, cron jobs, and background services in one test plan. Staging comes first, followed by business acceptance and production deployment.
OPNsense and lifecycle
Minor updates and major upgrades receive different assessments. Review release notes, rule changes, DHCP, VPN, and removed features early. Observe and test new approaches, then prepare migration before the old feature disappears.
Who tests, who approves, who accepts operations.
With your team, we agree on technical execution, business test cases, approval authority, and escalation. If a test fails, the next rollout stage stops while the agreed recovery or corrective action is decided.
Your platform is missing from our overview? We assess vendor upgrade paths and operating requirements to develop an individual update plan. Larger infrastructure and migration projects are coordinated with DAXS services.
Start with a manageable pilot.
Tell us about your systems, the bottleneck, and the desired outcome. Together, we define the first testing and approval step.