INTRO: For a long time, our default Runtime (Hosting Zone in Portal - Hostname Settings) has been "Europe" - a Windows-VirtualServer based environment. This environment will no longer be updated with newer features and improvements. For quite some time now WEM has been working on Cloud-Agnostic Kubernetes Runtimes. These can come in several forms: Private. Dedicated and Shared.
Existing projects on the Europe (Windows) Runtime, that need certain new features or improvements (*), can be migrated by WEM to the Shared Kubernetes Runtime (or a private runtime - depending on situation, license, contract, partnership etc).
Migration will be done on a per-project approach - it involves checks for resources, planning, testing (by project team and customer) and the application needs to be offline for the duration of the data-migration.
Attachment provides some background information, details about the steps to be taken (mostly by WEM) to perform the migration and important changes and potential consequences for the application that Project Team and Partner/Customer have to know and understand as there may be other changes at external parties (DNS, SAML/OAuth App Registrations, SMTP, API integrations) to be addressed and managed (out of scope for WEM).
HOW to get your project migrated to Kubernetes Shared Runtime?
- Read the information in the attached document and prepare based on what you learn.
- Start a Request for Migration by creating a Ticket in MyWEM Support (for paper-trail and working out the details).
- In ticket, provide detailed information about the projects (at least Project IDs) that you want to have migrated.
We typically do one project at a time, because of the offline and testing periods required.
- Provide details about potential dates and times that are considered convenient for your application to be offline and functional updates are not planned for publication. We will try to accommodate and plan as best as possible to make it convenient to both WEM operators and you. We do prefer office hours for Staging, and we can do early evenings (starting between 18:00 and 20:00 Amsterdam/CET Time) for Live migrations.
- Please indicate if you agree to a hard offline managed by WEM - all incoming requests will be blocked using IP restrictions and users get a HTTP 403 error in browser. If you want to have a more user-friendly solution showing a Maintenance Page, you will be responsible to make sure that no flowchart that makes changes to data can be accessed via homepage, menu/navigation items, API-calls, scheduled tasks etc. During data migration it is absolutely imperative that there is no change made to the data - it can lead to data integrity issues. The safest way is our hard offline option.
- We typically take a week between migrating Staging and Live, so you have a week for testing - so make optimal use of that period and make sure you have your testing plan and resources available.
IMPORTANT:
Understand that hostnames will change - DNS records, API calls, SAML/OAuth Application Registrations, existing Scheduled Tasks all may require changes - please address and plan appropriately (Responsibility with Project Team ).
- PDF: the Kubernetes runtime uses a different PDF render engine. This means, ALL PDF templates need to be tested and checked. If PDF templates use custom HTML or custom CSS, the results may be very different. This must be addressed in the PDF Templates. Contact WEM Support in case of uncertainty and specify the Node IDs of your PDF process nodes.
- SAML SSO Application Registrations.
- OAuth Application Registrations.
- Incoming Webservice Calls on exposed webservices from external applications.
- SMTP settings (the default WEM SMTP is no longer available - check our other forum posts on SMTP options).
- Existing Scheduled Tasks (schedules managed externally of via EasyCron).
IF you are using your own domain, there should be a CNAME Record in your DNS. This needs to change as well and it is wise to first change the existing CNAME record's TTL (Time To Live) to a short value (10 minutes) and when the migration is planned for execution, keep a DNS administrator on speeddial to make that change.
The time needed to migrate a project mostly depends on the size of the database - which is usually much larger in Live compared to Staging, so it should be obvious that the Live Migration itself may take longer. Very large databases may take up to 90 minutes, to give some indication. For a standard migration, we take a minimum of 30 minutes for the application to be offline.
(*) New features or improvements to decide to go for migration may include any of the following:
- TLS 1.2 and up (Europe hosting zone still supports TLS 1.0 and 1.1 but will use the best possible option based on the connecting client);
- WEM Tasks: Async (within user session) or Scheduled.
- Copy Data Node.
- Custom HTTP Endpoints.
- AI and Agentic AI features.
- Content Security Policy options.
- Future improvements.
Ralph - WEM Xpert since 2011
"I speak to machines with the voice of humanity"
-- Marillion, Man of a thousand faces --