Unreasonable version woes in FME Flow

I’d expect to be honest, do you not have the backup from 2025.1.2 available?

Be interested to here about the issues encountered.

Just upgraded from 2025.1 to 2025.2 (Build 25815) in a Dev environment and the only issue we’ve discovered so far was resolved with a package upgrade.

Alas no.

I upgraded Flow from 2024.x to 2025.0.3, then to 2025.2 beta, then to 2025.2.1. I.e. no 2025.1.2.

The latter two upgrades was due to testing Early Adopter stuff including Data Virtualization.

The breaking change was a gotcha, demanding a downgrade to 2025.1.2, resulting in a loss of backup.

My breaking issue has to do with HttpCaller certificate files and (perhaps) TLS 1.3, but this thread is of a more general nature.

Hi Lars,

I'm really sorry to hear that you've run into these version issues. Let's start with some answers to your questions before we explore potential remedies.

Re: Version guardrails and backups - One of the main obstacles to restoring backups into older Flow versions is that upgrades and improvements between versions often require updates to Flow’s internal data model. This can include database schema changes, defaults, derived values, and how missing information is interpreted. As an example of how this can complicate backwards compatibility, let's look at two hypothetical connection schemas:

Let's say that in the older (hypothetical) version of Flow, connection credentials were stored directly within the connection table:

connections (
  id,
  username,
  password_plaintext
)

However, in the newer (hypothetical) version, security has been improved by normalizing credential storage, and secrets are now moved to a dedicated, encrypted credentials store:

connections (
  id,
  username,
  credential_id
)
credentials (
  id,
  secret_encrypted,
  encryption_version
)

Once this update has been applied, the original plaintext password no longer exists, and the older Flow version has no reliable way to reconstruct the data. 

Of course, there are many variations on this example, but the core dilemma at play is the same: once changes like this are applied and a backup is created, restoring that backup into an older version would require Flow to recreate data that doesn't exist in the current version.

Re: Why not restore with warnings about potential problems - This stems from the backwards-compatibility dilemma outlined above. Some changes cannot be undone but are easily detectable (as in the previous example of credential normalization); there are also some changes that cannot be reliably detected. 

For example: Let's say that an older version accepted NULL values for timezone (defaulting to server local time), but the newer version no longer accepts NULL values for timezone and instead defaults missing values to UTC. In a downgrade scenario, the older version would have no way to know whether a timezone  value of UTC was explicitly set by the user or filled in during the upgrade. 

That's a very limited example but hopefully it helps illustrate the crux of this issue. Allowing a backwards restore operation with warnings would create a situation where the older version is handed data structures and logic that it was never designed to interpret. Even if the restore appears to be successful, the resulting behavior could be unpredictable and difficult to diagnose. Due to these risks - and the potential for catastrophic situations - FME Flow does not support restoring backups into older versions.

Finally, if you are looking for ways to migrate content from 2025.1 to 2025.1.2: While full configuration backups can’t be restored to older versions, Projects are useful in situations like this since they can export (and re-import) content such as repositories, workspaces, and related resources in a more version-tolerant way. Projects don’t capture the system state as comprehensively as backups (which include users, schedules, credentials, etc.), but if you need to rescue any core content from 2025.2 it might be a partial solution.
 

Hi carlw

I appreciate the pitfalls and problems with doing a backward restore, so a 100% restore can never be expected to work. But usually there are relatively few changes between close versions (here 2025.2 and 2025.1).

It would be nice, if at least the parts that are _not_ different between the versions in question could be restored. E.g. workspaces and schedules. The current rejection is absolute and forced, which is what I think is unreasonable.

Hi Lars,

Fully agree, it would make life much easier if there was a bit of nuance to how errors are handled during restore operations.

I do have some good news to share on that front - work is already underway to deliver this functionality at some point in the near future! I can’t share details at this time, but the goal is to address some of the exact version woes you’ve encountered here with a more graceful approach to error handling. 

Feedback from longtime users like you is so valuable and really does help guide the future of FME. Based on what I’ve seen, I think you’ll be pleased with these upcoming changes. 

Best,
Carl