In this guide
01 / Define what maintenance is responsible for 02 / Keep ownership understandable and recoverable 03 / Test recovery instead of assuming a backup is enough 04 / Use a repeatable change and verification process 05 / Agree on routine checks and incident communicationDefine what maintenance is responsible for
A website continues to depend on people, systems, and business information after launch. Forms may connect to a database. Staff may use an administrative application. Content, service coverage, and external integrations can change. A maintenance agreement should name the parts being supported and the checks that show they still work.
Start with the journeys the business cannot comfortably lose: customer inquiries, account access, an order or quote workflow, and any internal process that depends on the site. Then list the supporting components, such as ColdFusion, MySQL, hosting, the domain, certificates, and third-party services.
Define what requires a planned project rather than routine maintenance. A new feature, a major data migration, and an emergency investigation have different scopes. Clear responsibilities help the owner know whom to contact and what information is needed when something goes wrong.
Keep ownership understandable and recoverable
Make an inventory of the domain registrar, hosting account, database, source files, and services the application uses. Record the business owner and the authorized technical contact for each. The inventory should explain where access is managed without placing passwords in a shared document.
Confirm that the business can obtain its current source and necessary data through the agreed process. Keep deployment notes, configuration requirements, and the location of backups with the project records. A folder full of files is not a complete handover if nobody knows which version is live or how it connects to the database.
Review access when staff or suppliers change. Keep the access decisions separate from public website content and use the business’s established secure process. The goal is a clear, usable ownership trail, not a new set of accounts created during an unrelated content update.
Test recovery instead of assuming a backup is enough
A useful backup plan identifies what is copied, how often, where it is retained, and who can restore it. Files and databases may need coordinated copies to represent a usable version of the application. Decide how much recent work the business could tolerate losing and how long an interruption would be acceptable.
MySQL’s backup and recovery documentation describes different backup methods and point-in-time recovery options. The suitable method depends on the application and operating environment. Choose it deliberately and document the restore procedure; a timestamp on a backup file does not prove the application can be recovered. [10]
Schedule a restore check in an isolated environment when it fits the support agreement. Confirm that restored data, files, and configuration support the important workflows. Record how long the process took and what was missing. Protect the restored data with the same care as the original and keep the test separate from production.
Retain the results with the maintenance records. If the restore instructions work only in the memory of one developer, the business still has an avoidable dependency.
Use a repeatable change and verification process
Before an update, identify the affected feature, preserve a recoverable previous state, and define how the change will be checked. Review platform and dependency updates against the versions actually in use. Test relevant behavior in an appropriate development or staging environment before publishing.
For a customer form, useful checks include a valid submission, invalid input, and a backend failure. For a database application, include role permissions and representative data. For a content change, review links, headings, metadata, and narrow-screen readability. Match the checks to the change rather than relying on the homepage loading.
After release, read the live result back and confirm the version or behavior expected. Record the changed files or records, the validation result, and any remaining limitations. Have a defined way to return to the earlier state if the update creates a problem.
Agree on routine checks and incident communication
Routine checks can include the main contact path, domain and certificate renewal ownership, visible errors, backup completion, and planned restore exercises. Choose a cadence around the application’s importance and rate of change. A frequently updated business application may need a different review plan from a small information site.
When reporting an incident, include the page address, the action taken, the approximate time, and the visible error. State whether the issue affects one user or several known users. Do not send credentials or confidential customer records through a public inquiry form.
Ask the maintenance provider to explain response arrangements, coverage hours, exclusions, and how larger repairs are estimated. Avoid assuming that a maintenance plan includes continuous monitoring or immediate response unless those services are explicitly agreed.
Full Blown can help support an established site or review a ColdFusion and MySQL application whose ownership or recovery process is unclear. A useful starting point is the current website, the essential workflows, and the documentation already available.
Related services
Sources and further reading
Related reading
- When should you replace spreadsheets with a database?
- A website redesign checklist that protects useful URLs and customer inquiries
- How to scope your first custom business application
- Explore all Insights
Let’s discuss your next step.
Bring the problem or the workflow. We’ll help define a practical scope.
Request a consultation