Post-launch support and maintenance

Launch is the start of the operating life

A Drupal platform that is finished on launch day is already late. Core publishes releases. Contributed modules publish security advisories. Editors find the three fields that should have been one. The useful support arrangement is the same people who know the configuration, on a rhythm you can plan.

GeoNovation stays after go-live for that reason. Updates are applied, reviewed, and deployed the way the original build was deployed. A security release is not left for a quiet month. A small change is made in the module or the config, not patched on the server.

What the arrangement covers

Support here is the continuity of the platform, not an open purse for unrelated work. We agree the surface: Drupal core and the contributed projects you depend on, the custom modules we wrote, the theme, and the incidents that stop publishing or the public site. New products and large features are a separate brief, estimated before they start.

You keep the repository, the configuration, and the documentation. Support does not make the platform dependent on us being the only people who can deploy it. When your own team is ready to take a release, the handover is the point of the engagement.

• Core, contributed, and custom updates applied on a schedule.
• Security releases treated as part of the work, not an exception.
• Small fixes and editorial support on the system you already run.
• A written record of what changed, so the next person can see it.

How to start

Tell us the Drupal version, who deploys today, and what "broken" means for your editors. We reply within 24 hours. If the platform was not built by us, the first step is reading it: modules, hosting, and the update debt, before anyone promises a retainer.

This work sits inside Drupal Development. Start a Drupal project — tell us the organisation, the platform, and the constraint.