How amazee.io Helped Renesas Modernize Enterprise Hosting Without Disruption

Renesas, a multinational company focused on automotive, industrial, and IoT technologies, runs a large enterprise website that plays a central role in its global operations. Built on Drupal and powered by an extensive database and large volumes of digital content, the site had outgrown its legacy hosting environment. Delays in support, inflexible infrastructure, and mounting security concerns were affecting day-to-day work and long-term planning.

To address these issues, Renesas partnered with amazee.io, known for its open-source hosting platform and direct, developer-friendly support. The project commenced with a structured discovery phase, during which both teams collaborated to analyse the application, comprehend existing workflows, and devise a migration plan that would minimise disruption. The solution was hosted within a dedicated cloud environment, designed specifically around Renesas’ needs.

The migration was completed with zero downtime and included performance tuning, workflow optimisation, and real-time support integration. Following the migration, Renesas reported a 10% improvement in processing speed and a more secure and stable environment. Their development team also gained greater independence, supported by on-demand access to amazee.io experts.

To understand the approach behind this transition, The Drop Times spoke with Rolando Scott, Solutions Lead at amazee.io. They shared how careful planning, open communication, and a focus on operational fit made the project not just a success, but a long-term improvement to how Renesas runs its web infrastructure.

During the initial discovery phase, amazee.io worked closely with Renesas to understand the site’s architecture and spot potential friction points. One of the first technical needs that surfaced was around logging: Renesas required that all container and application logs be shipped to their preferred observability platform. While not entirely out of the ordinary, this still required a smooth integration within amazee.io’s Kubernetes-based environment. To meet this, a custom logging pipeline was built, ensuring that operational data flowed to where Renesas needed it without disrupting the new setup.

The database posed a more significant challenge. It was substantial in size, and moving it between environments required a tailored migration strategy. The solution involved creative problem-solving and ultimately inspired a new backup system that amazee.io now offers more widely, but it started with Renesas’ specific needs.

Another requirement was adapting the network setup. Renesas runs its own internal edge security solution instead of using amazee.io’s default stack. The platform was reconfigured so that only Renesas’ approved tools could access the cluster—a nonstandard request that was implemented successfully through close collaboration.

He added,

“That kind of network lockdown of third-party CDN isn’t default, but we figured it out with them.”

Beyond the infrastructure, the migration marked a shift in working culture. The Renesas team, experienced in more traditional environments, had to adjust to Kubernetes concepts such as containerised services and ephemeral pods. Supporting this transition meant more than technical enablement; it meant aligning expectations and building trust.

Rolando noted,

“We also had to learn how their team thinks. They're sharp, but they came from a very different setup. So part of the challenge was helping them shift how they approach things: thinking in containers, getting used to how Kubernetes works, understanding that pods just disappear and come back, that kind of behaviour.”

To keep pace with evolving needs, the migration roadmap was updated frequently, sometimes multiple times a week. This iterative approach allowed the teams to adjust priorities in real-time and address unforeseen constraints without stalling progress.

“The roadmap couldn’t be static. We updated it constantly, sometimes more than once a week, based on how they were progressing, what questions were coming up, and what was shifting on their side,” he said.

In terms of operations, critical processes such as cron jobs, data import/export, and queue workers were preserved without disruption. amazee.io replicated the existing environment and gradually introduced enhancements, avoiding unnecessary rework at launch.

“We started by mapping out their current setup (cron jobs, queue workers, import and export routines, etc.) and did a straight lift and shift to get things running in the new environment. It wasn’t about re-architecting everything from day one. The goal was to keep it working, then refine,” he explained.

As the migration deepened, both sides began to adjust. The Renesas team grew more comfortable with the platform and began adopting a more cloud-aligned mindset. While not fully “cloud-native,” the workflows became well suited to Kubernetes, what the amazee.io team calls “cloud naturalized.” The shift happened organically, through collaboration and support.

“There’s very little that is ‘self-managed’ about it on their end. We handle the platform, the infrastructure, and the automation,” Rolando said. “They don’t have to touch that layer unless they want to.”

By the time go-live came, the teams were aligned and ready. The transition proceeded as planned, with rehearsals and contingency steps already in place.

“There were backups, rollback plans, freeze windows, all the usual stuff. But because their team had been so involved throughout, it didn’t feel as high-stakes when we flipped the switch. Everything mostly just ran,” he added.

Security was another area of shared responsibility. While Renesas maintained control at the edge, amazee.io focused on internal infrastructure hardening. The configuration was tuned to align with existing threat models, and pre-launch testing ensured readiness.

“They didn’t bring in additional tools like Signal Science or Fastly; it’s all their tools, end-to-end. What they needed from us was support to make sure the new cluster wasn’t a soft spot,” Rolando said.

To confirm performance, an independent firm conducted load testing. The results were used to fine-tune the setup. Since going live, the platform has remained stable, with no downtime or performance degradation.

Rolando further explained,

“They brought in a third-party to run load testing, and we collaborated with them to interpret the results and make any needed adjustments. Since go-live, things have held up well—no security incidents, no performance issues.”

One of the most tangible changes post-migration was the transition from a traditional ticketing system to Slack-based real-time support. This was a pretty big shift for them. They came from a legacy ticket-based system where everything had to be filed, queued, triaged, and then eventually picked up, often being shifted from one responsible person to another.

Shifting from a traditional ticket-based support model to real-time support messaging within the customer’s preferred platform represented a minor cultural shift.

“Moving to real-time support messaging was a culture shift that has improved responsiveness, collaboration, and has proven to be a substantial and quantifiable value-add to the support relationship.”

Onboarding into this new model was structured to match Renesas’ technical expertise. Clear communication norms were established, and both teams shared visibility into infrastructure health, which eliminated silos and built mutual trust.

“We don’t just throw people into our support messaging tool and expect magic,” he said. “There’s a kickoff where we set norms, introduce support engineers, and explain when and how to use the channel effectively.”

Ultimately, the migration was more than just technical execution; it reshaped how Renesas’ team works and collaborates. The result is a scalable, secure, and responsive web platform that feels like an extension of their own operation.

To read the full case study or download a copy, visit: Renesas Enterprise Hosting Platform Migration | amazee.io