Cloud migration, step by step to 100% success

After the assessment, comes the actual migration to the Cloud. This article aims to illustrate how Digora supports the company down to the smallest details of its project. Nothing is left to chance, as a well-executed migration helps build the company's and its teams' confidence in Cloud services, which they will use on a daily basis.

Ensuring Portability in the Cloud: Evolving the Architecture

IaaS, PaaS, or even SaaS? This question naturally arises very early, as early as the assessment, since it entirely determines the method. PaaS and SaaS only support assets that are up-to-date and Cloud-ready.

However, with third-party applications whose vendors have not yet embraced the Cloud, in-house applications that cannot be maintained, and databases that have never been upgraded, a Cloud migration can quickly become questionable.

While combining up-to-date updates and migration remains feasible with rigorous methodology and extensive dry-run testing, it is generally not recommended. 95% of databases never benefit from the latest updates. Migrating an outdated version (a common scenario in enterprises), especially one that is no longer supported, requires significant time and attention.

We usually recommend opting for an iso migration first and then performing the version upgrade once in the Cloud. This approach allows provisioning  sandbox environments at a lower cost, which can simply be shut down at night. This is also the most common strategy, as few companies have the on-premise servers, storage, and CPU capacity available for an upgrade before migration.

While the migration approach remains the same regardless of the chosen CSP, challenges often arise at the application level, as they can be the most resistant to Cloud migration. This can introduce additional delays, especially if they depend on a vendor’s schedule. However, this process is also an opportunity for companies to modernize their in-house applications, enhance security by implementing patching sessions, and optimize their IT infrastructure.

Best Practices for Migration

Two key aspects require special attention: security and networking.

Regarding security, CSPs offer various tools (bastions, two-factor authentication, etc.), sometimes free or at low cost, given their ease of implementation compared to complex on-premise licensed solutions.
However, assessing the company's actual cybersecurity needs remains essential to avoid paying for bundled solutions that may include unnecessary features.

Additionally, security also involves regulatory compliance. DEEP ensures that its CISO works with the company's DPO to translate legal requirements into technical implementations. Whether dealing with GDPR, financial data, or healthcare data, it is crucial to involve the Cloud Provider to ensure they hold the necessary certifications.

The network aspect can present challenges depending on the company’s location, interconnections, and project size. Setting up network links involves multiple stakeholders, potentially delaying the migration by months if not addressed early or if physical implementation is required.
For large-scale Cloud migrations, dedicated and robust network links may require infrastructure work, whereas smaller projects can usually rely on a classic IPsec VPN.

Beyond the network itself, network traffic architecture must be carefully planned to avoid latency issues caused by excessive network hops within the CSP.

POC and the Actual Migration

A company moving towards a hybrid or multicloud infrastructure benefits from a POC before going live. A POC allows evaluating the project's feasibility, real performance needs, and network architecture over several months without significant costs. It is also a great opportunity to test updates, assess their impact on applications, and identify failed queries. Additionally, it enables teams to explore new services and features in databases.
Once validated, the environment is retained as a production environment.

Outside of the POC, a staging environment is created for a dry-run migration, primarily to assess the actual downtime the company can tolerate. If no downtime is acceptable, live migration mechanisms must be employed.