Cloud applications on Easy8 domain

Who does this concern

Administrators of applications hosted in the Easy8 Cloud. Short answer: in almost all cases you do not need to do anything.

What is happening

In early November 2026, new domains will be enabled for Easy8 applications on cloud. Your subdomain does not change. Only the domain after it does.

Now	After the change
[your_domain].easyredmine.com	[your_domain].easy8.com
[your_domain].easyproject.com	[your_domain].easy8.com
[your_domain].easyproject.cz	[your_domain].easy8.com
[your_domain].easyproject.hu	[your_domain].easy8.com

This is not a migration and not a move to a different server. Your application, your data, your users, your licence and your version stay exactly where they are. We only add a second address that points to the same application . The address change is not related to version update, it is an independent action.

Until 31 October 2026, you can request the address change to be postponed . Conditions for postponement are explained below.

The original domain will continue to exist and work on your application for at least 12 months after the change .

Why the change?
Products Easy Redmine and Easy Project became Easy8 in March 2026. The cloud applications are the last part of the brand that still runs on the old addresses.

How the change works, and why the old address keeps working

What we add

We enable a URL alias . From that moment your application answers on both the old address and the new easy8.com address, with a valid certificate on both. This is a web server configuration, not a data change. Nothing on the old address is removed or switched off.

Multiple tests on the production environment have been conducted to verify the technical process.

What we change inside the application

A couple of things change only if you never customised them.

Login page. The login page is the only page which enforces the new address (via redirect). All unlogged visitors will always reach the login page on the easy8.com domain. After logging in, any links you click to the old or new domain will both work.
Host name in the application settings. The application keeps its own address in Administration >> Settings >> General. It is used to build absolute links in e-mail notifications, exports and generated documents. We set it to the new address. In practice this means notifications sent after the change point users at easy8.com, while notifications sent before the change keep pointing at the old address, and both work.
Application name in Administration. Renamed only if it still holds the default value, which was the original URL. If you set your own name, we do not touch it.
Sender name in outgoing e-mail. Renamed only if it still holds the default value.

What we do not change

The REST API is not redirected. Both addresses serve the API on all paths.
No data, no users, no permissions, no attachments, no licence.
No extra downtime beyond the normal restart that comes with any update during the maintenance window (1:00 - 4:00 at night)
Nothing on the old address is deleted.

The practical consequence: old bookmarks, links inside old e-mail notifications, scripts and integrations that call the old hostname all keep working. The alias is additive.

What this means in practice

Cases that are safe, with no action from you

Case	Why it is safe
Bookmarks, saved links, links pasted in chats and documents	Both hostnames resolve to the same application
Links in e-mail notifications sent before the change	Both hostnames resolve to the same application
REST API integrations, own scripts, n8n or other automation platforms calling the API with a token	API paths are not redirected, both hostnames answer
Mobile and desktop clients pointed at the old hostname	API paths are not redirected, both hostnames answer
Reports, dashboards, saved filters, custom fields, workflows	Nothing inside the application depends on the hostname
Internal documentation and user habits	The old address keeps working, so you can update your docs at your own pace
Visibility in search engines	Cloud applications are served with a noindex robots header, so they are not indexed either before or after

The reason all of this is safe is the same in every row: we are adding an address, not replacing one.

Cases we handle proactively with you

Some applications are excluded from the automatic switch .

SSO and SAML, and OAuth 2.0 or OIDC where an external identity provider is used. Your identity provider (Microsoft Entra ID, Okta, Google Workspace and others) stores the exact address of your application in its configuration: Sign-on URL, ACS URL, Issuer, Metadata URL, Callback or Redirect URI. If the login page starts enforcing a new hostname while the identity provider still expects the old one, login stops working. We will manage such applications individually with their administrators.

The agreed sequence is:

Your Customer Success Manager or our support approaches you with the detailed steps to take.
If your identity provider supports multiple values, for example OAuth redirect URIs or Entra ID reply URLs, add the new ones next to the existing ones. Where it accepts only one value, for example a Google Workspace ACS URL or an Okta audience URI, we agree a cut-over window with you instead. You confirm what you changed, we switch the address, and you test the login before we consider it done.
You confirm in writing that the change is in place.
We switch the address in an agreed time.
You test the SSO login on the new address and confirm it works.
Your old values stay in your identity provider until we confirm separately, in writing, that the old hostname has been retired.

Applications where Easy8 acts as the identity provider for your other systems. The dependency runs the opposite way as the first point, and is assessed case by case.

If you are using one of these groups, wait for us to reach out. You can also contact us first if you want to plan it into a specific maintenance window.

Only applications on version 16 will be switched. Applications without updates - for relevant prior reasons - remain on original domains.

Cases outside our control

We cannot see or change anything that lives on your side. While the alias is active none of these break, but each one needs to be dealt with, or at least checked.

Network allowlists. Firewalls, proxies, CASB, secure e-mail gateways and DLP tools that permit the old hostname explicitly. Add easy8.com now, otherwise your users will reach the new login page and be blocked by your own network.
Integrations you built yourselves. Scripts, connectors, middleware, low-code flows, reporting tools and data warehouse jobs that hold the old hostname in configuration. They keep working on the alias. They must be repointed before the alias is retired.
Third-party systems that store your address. Ticket routing, ERP, CRM, BI tools, service desks and webhook receivers.
Certificate pinning or strict hostname validation in your own tooling.
Password managers, browser profiles and corporate portal tiles , which will treat the new hostname as a new entry.
E-mail rules and filters built on the sender name or on the link domain.

Our recommendation: make an inventory of every place that contains your old address, keep it as a list, and work through it during the alias period. It is a short task done early and an unpleasant one done late.

Asking for a postponement

If the change lands at a bad moment for you, you can ask us to postpone it. The deadline for requests is 31 October 2026. Contact your Customer Success Manager or our support in writing and state the reason.

A postponement means your application keeps its current primary address for now and receives the alias later.

We ask for a reason because we want to address real blockers, if they are deemed as such. Reasons we accept include:

An SSO, SAML or OAuth configuration you cannot change inside the window, for example because the identity provider is managed by a different team or a different company.
An active change freeze, an audit, a certification or a validated environment that would require re-validation.
A corporate allowlist you do not control and cannot get changed in time.
A self-built integration on the current hostname that you cannot retest in the window.

Reasons we do not accept on their own are the ones the alias already covers, for example that bookmarks would break, that API scripts will break, or that users will be confused by a new address. If that is the situation, we will do one of two things: explain precisely why your case is already covered, or handle it technically on our side so that the concern goes away.

Timeline

When	What
Until 31 October 2026	Window for postponement requests.
From November 2026	The URL alias is enabled.
From November 2026 onwards	Applications with SSO, SAML, OAuth or a custom repository are handled individually.
At least 12 months after your switch	The old address keeps working in parallel. This is the minimum we commit to.
Announced in advance, no date set yet	Retirement of the old address.

The last row is the important one. We have not set a date for retiring the legacy hostnames, and we will not remove them without notice. When the decision is made, we will announce it in advance and in writing, so that you have time to repoint anything remaining on the old domain. Until then, both addresses work.

Checklist for administrators

Nothing is required from you to change in the application.
If you use SSO, SAML or OAuth with an external identity provider, wait for our contact, or contact us if you want to schedule it.
Add easy8.com to your network allowlists.
Write down every place that holds your old address, and repoint it at your own pace.
Update your internal documentation when convenient.
If you need a postponement, ask before 31 October 2026 and please tell us why.

Frequently asked questions

Will my users have to log in again?
The switch includes an application restart, so active sessions end. Users log in again on the new address.

Will the old address stop working the moment the new one appears?
No. Both work in parallel. The only redirect is on the login page.

Do I have to rewrite my API scripts now?
No. The API answers on both hostnames. Rewrite them before the old address is retired, which we will announce well in advance.

Will links in old e-mail notifications still work?
Yes.

Can I keep the old address as the primary one permanently?
No. The legacy domains will be retired eventually. The alias exists to give you time, not to keep two addresses forever.

Does anything change in pricing, licence or contract?
No.

We use a custom domain of our own. Does this affect us?
Partly. The application itself is not renamed, and the settings we change are already customised in your case, so we leave them alone. What does concern you is where your custom domain points. If projects.company.com is a CNAME to your legacy address (company.easyredmine.com), that CNAME resolves only as long as the legacy DNS record exists, so you will need to repoint it before the legacy hostname is retired (still plenty of time). A CNAME cannot hold two targets, so this is a repoint rather than an addition. The same applies if you run your own reverse proxy with the legacy hostname as the upstream. We will confirm the target to use and give you notice well before anything is retired.