Case study · Membership
ICGN
A Drupal 10 migration for the International Corporate Governance Network, with the hosting architecture redesigned at the same time.
- Client
- International Corporate Governance Network
- Scope
- Drupal 10 migration and AWS architecture
- Platform
- Drupal 10 on AWS
- Users
- Members, event delegates, course students
The problem
ICGN brings together investors, companies and policymakers around corporate governance and investor stewardship. Its policy work, global events programme, member resources and education courses all run through the website, for a membership spread across every time zone.
The site had to move onto Drupal 10. Doing that alone would have carried the same hosting limits onto a newer CMS, so ICGN treated the upgrade as the moment to fix the architecture underneath it as well.
What we had to solve
A membership with no quiet hours
Members, delegates and students use the site from every time zone, so there was no overnight window in which an outage would go unnoticed.
Nothing lost in the move
Content, member data and every custom feature had to arrive on Drupal 10 working as before, or the upgrade would cost more than it saved.
Architecture decided on purpose
Instance sizing, database set-up and failover had to be designed and written down, so the platform could be reasoned about after launch.
Security at the edge
Protection had to sit in front of the application, filtering traffic before it reached Drupal, not only inside it.
Two moves at once
The CMS upgrade and the hosting redesign were planned together, so the site moved once, onto a platform designed for it, rather than twice.
Architecture review
We reviewed the existing set-up and wrote a high-level design for the target AWS platform, agreed before any infrastructure was built.
Low-level design
Instance sizing, database configuration and failover behaviour, each decided and documented so the platform can be reasoned about later.
Validated on Drupal 10
Content, member data and every custom feature were checked against the new codebase before cutover, not after it.
Cutover onto the new platform
The site moved onto load-balanced AWS servers, with the database on RDS and a read replica, and AWS WAF in front.
What we built
A Drupal 10 site on an AWS platform designed for it: load-balanced application servers, a managed RDS database with a read replica for resilience and reporting, and AWS WAF filtering traffic before it reaches Drupal.
Every decision behind it is written down, from instance sizes to failover behaviour, so the platform can be changed with confidence rather than by trial and error.
Drupal 10
Content, member data and custom features moved across with nothing lost.
Load-balanced AWS
Application servers behind a load balancer, sized from the low-level design.
RDS with a read replica
A managed database with a replica for resilience and reporting.
AWS WAF
Application-layer protection in front of the site.
The outcome
A clean move to Drupal 10 with no loss of content, member data or functionality. On the new platform the site has run at 99.99% uptime, with average page loads under two seconds.
How we keep it runningICGN: AWS hosting and Drupal support at WebsiteSupport.io →
Got a process like this?
Applications, assessments, panels and deadlines. Thirty minutes on the phone is usually enough to tell you whether it is a six month job.