Building Drupal websites is all nice and fun, but once the site or application is launched, too many companies just let their digital assets run on cruise control until the next major overhaul. Symetris spends almost a third of its resources on maintaining and enhancing existing websites. During this talk, we'll share what we consider are best practices to make sure you get the most return on your initial investment in a Drupal platform.

1. DrupalCamp Montreal 2017 – Symetris.ca

2. 1. Introduction
2. Cost of inaction: Impacts and risks of NOT
evolving/maintaining your Drupal website
3. Benefits of evolving and maintaining your Drupal
website
4. How to approach maintenance/enhancement of your
Drupal website
5. How to budget maintenance

3. Introduction

4. ***
• Founded in 2004 – 14 years ago!
• Masters of Drupal since “Drupal 5”
• Drupal maintenance experts
• Regular Drupalcamp presenters and sponsors

6. Brad Muncs
President @ Symetris

7. ○ So 2008!
○ Drupal is standard, easy to find developers
○ Digital is major element of organization
strategy, from marketing & bizdev to
operations and fulfillment

8. ○ Super old sites
○ Sites on D6 (no longer maintained)
○ Sites that are not strategically important for
organization
=> This begs question: why is your digital not important? Very
strange in 2018... Strategic orientation issue for your
organization?

9. • One-off websites: but why would these be on
Drupal?
> If it's part of a multisite, then your multisite definitely needs
evolution/maintenance
• Upgrading from D7 to D8?
See my other conference LINK

10. Chapter 2

11. ○ Loss of market share
=> Reduced credibility
○ Higher long-term cost
=> "Invisible" upcoming cost of redesign
=> Money and time of internal resources
=> "Unpredictable" costly events like hacking

12. ○ Less dependable results
=> More bug-prone when making changes
=> Cycle of rush & bench
○ Sporadic fixes/enhancements more costly
=> Less documentation or knowledge of system

13. ○ High risk
=> Growing risk of security vulnerability
=> Growing risk of incompatible dependencies
○ Low performance
=> Incompatibility with rest of digital ecosystem
==> More manual/error-prone data sharing
=> Performance issues
==> More "patches"

14. ○ Bad decisions
=> Lack of relevant data on consumer behaviour
○ Irrelevant website
=> No flexibility
=> Disconnected from ongoing campaigns and market strategy
=> Wasted investment

15. ○ Time-consuming data entry
○ Less efficiency
=> Loss of motivation

16. ○ Loss of trust in your organization
=> Less user-friendly interface
=> Difficulty to find relevant information
=> Incompatibility with browsing device

17. Chapter 3

18. ○ Reduced TCO (total cost of ownership) which
leads to better long-term ROI
=> Extended website longevity
=> More budget for experimentation and enhancements

19. ○ Better, faster deployments
=> Sophistication of deployment workflow
=> More “bite-sized” deployments with less risk
○ More predictability
=> Ongoing stream of work makes it easier to plan ahead
=> Proactive enhancements

20. ○ Less risk
=> Significantly reduced risk of hacks and downtime
○ Better performance
=> More digital ecosystem integrations
=> Enhanced performance and scalability

21. ○ Reach more customers
=> Adapt to new devices or channels
○ Website becomes cornerstone of content
strategy
=> Constantly updated
=> Relevant new functionnality
○ Make better decisions
=> Based on user behavior data

22. ○ Enhanced management interface
○ Granular permissions
○ Save time and minimize errors
=> Enhanced publishing workflows
=> Can even be automated by synchronization

23. ○ Positive image of your organization
=> Information easy to find
=> Up to date and relevant features and content
=> Compatible with any browsing device

24. Chapter 4

25. ○ Minimize potential technical and security
issues
=> Regularly update modules to latest version and test
compatibility with your custom modules and code
=> Create/use unit tests
=> Create/use manual tests
=> Install monitoring services (NewRelic, etc)

26. ○ Have a plan for core / contrib updates. Who? when? what?
○ Have a plan for emergencies (drupalgeddon, recovery plan, etc.)
○ Write down who is accountable for what (server, application,
domain name, analytics, etc.)
○ Do some clean up (periodically remove unused : modules, roles,
content types, etc.)
○ Keep you deployment pipeline clean and your process clear

27. ○ Keep your test plan alive and build on top of it as you progress
○ Fight tunnel vision when improving the site, have your dev make
suggestion on how to do it better / more robust
○ Keep an eye open on the environment, it can make you site
instantly better if you plan for it (ex: php 7 much faster)
○ Write "onboarding" documentation

28. ○ Establish expectations regarding issue
corrections
=> How fast requests are acknowledged?
=> How fast they are addressed/corrected?
=> What is urgent vs standard?
=> Estimates provided over what nb. Hours?

29. ○ Sky’s the limit, but align to objectives
=> Backlog of wants/needs
=> Prioritization
=> New “phases” to project vs quick fixes

30. Chapter 5

31. ○ 17.5% of the initial cost of the website
=> 10% Bugfixes, minor changes
=> 5% Prevention (update modules, etc)
=> 2.5% Support
○ You can also plan for about 5-10%
of the cost per year for evolution

32. Contact us at info@symetris.ca
Presentation soon available on Slideshare
PS: We’re looking for Drupal developers! Send your CV!