Upgrade or Migration? The Secret Behind Successful Uniface Transitions

In this episode, Peter and Henk discuss the difference between a Uniface ‘upgrade’ and ‘migration. Henk shares his experience with dozens of migrations, explains why professional support is often essential and gives two of his biggest pieces of advice. The podcast concludes with a challenge to highlight the commercial perspective of Uniface users in future episodes.

Peter: Welcome to the Unicast podcast, the only podcast about Uniface. This is our third episode, and it’s starting to feel like a real podcast. Henk, are you still glad you joined me on this?

Henk: Absolutely, Peter. We may have taken on quite a commitment, trying to produce a new episode every two weeks. We need to keep in mind that we’re doing this because we enjoy talking about Uniface as part of our work.

Peter: I completely agree. It should be enjoyable to both listen to and record. In the previous episode, I mentioned that my interviewing skills might need improvement, so I thought I’d take this opportunity to practice by interviewing you!

Henk: You did mention it! Are you certain about this?

Peter: Let’s find out!

Henk: All right, what would you like me to do?

Peter: Nothing special. Perhaps imagine that you’re not already involved in this podcast and are genuinely interested in being interviewed.

Henk: Okay, I’ll go along with that.

Peter: I’ve prepared a few questions.

Henk: I suspected as much. Let me guess—they’re about the Uniface migration?

Peter: Indeed. My first question is actually about terminology. Why do you prefer to call it an “upgrade” while Uniface (or Rocket) refers to it as “migration”?

Henk: There isn’t a strict definition in the software industry for terms like upgrade, update, and migration; different vendors often use them interchangeably. Rocket uses “migration” to describe the transition between major releases, as these usually bring significant new functionality, which requires changes to the repository. You can’t simply use Uniface 10 with an existing Uniface 9 repository; it requires a migration process to adapt applications from previous releases.

Peter: So, are these terms actually interchangeable?

Henk: There is a distinction often made online:

  • An upgrade means switching to a newer major version, such as from Uniface 9 to 10.
  • An update refers to smaller version changes, like from Uniface 10.3 to 10.4.
  • A migration typically means moving to a different software product entirely.

From this perspective, “upgrade” is a more suitable term. Rocket generally reserves “migration” for changes to the application repository that align it with a new major version.

There’s much more involved in a major version upgrade than just repository changes. It often requires setting up and configuring a new development and deployment environment, which includes various testing setups, configuration management, build and test tools, license management, integration with third-party software, and sometimes even an upgrade to the operating system. So, “upgrade” better captures the comprehensive nature of the process, while I use “migration” strictly for repository-specific changes.

Peter: That’s a clear explanation, Henk. I’ll aim to use the correct terminology.

Peter’s question: How did you become an expert in migration—or rather, upgrading?

Henk: Expertise develops over time. As I mentioned in our first podcast, I worked at the Uniface Lab from 1989 to 2018, heavily involved in the development of Uniface 10 since around 2011. Starting in 2016, I began working on testing and refining the automatic migration process using real customer repositories. I visited customers in several countries to conduct live migrations and improve the automated process based on their feedback. In 2018, after a restructuring, I decided to become an independent Uniface consultant, specializing in comprehensive upgrades to Uniface 10.

Since then, I’ve completed numerous upgrades for various clients, sometimes on-site, sometimes remotely.

Peter: That sounds like an impressive record. How many upgrades have you performed?

Henk: Distinguishing between repository migrations and full upgrades, I’ve migrated several dozen customer repositories. Full upgrades, which encompass both repository and environment, I’ve performed for about ten clients, ranging from simple client-server applications to complex setups involving numerous applications and services.

Peter: Some might say that anyone can perform a migration since Uniface has built-in migration functionality. How would you respond to that?

Henk: While the automatic migration tool is helpful, the upgrade process involves much more. The Uniface Lab has automated repository migration to ensure compatibility at deployment, so applications work similarly in Uniface 10 as they did in Uniface 9. However, no tool can anticipate every situation that may arise in a unique application setup.

Most companies perform an upgrade only once every decade or so, meaning this isn’t something developers get regular experience with. Additionally, developers aren’t always familiar with configuring deployment environments, and assignment files can become cluttered over time.

Peter: So, your experience helps bridge those gaps?

Henk: Yes. After performing many upgrades, you develop an intuition for potential challenges. Even repository migrations may require multiple iterations. We’ve developed tools to analyze repositories beforehand and compare results after compilation, ensuring a smoother process.

I often compare upgrading to moving house. You can handle it yourself, but it can be time-consuming and disruptive. Or you can hire professionals who have the necessary tools and experience, making the transition much easier.

Peter: That’s a great analogy. The outcome is the same, but the process is much smoother with help.

Peter’s question: With all the upgrades you’ve done, what was the most challenging migration you handled?

Henk: That’s difficult to say. Each client has unique standards, procedures, and environments. The biggest challenges are often procedural or organizational rather than technical. It’s crucial to have internal support from various roles—application testers, QA, DevOps, project managers—all must be involved.

Peter: How long does an average migration take?

Henk: It varies. A repository migration depends on factors like size and repository age. If development began long ago, issues are more likely. Migrations are iterative, and changes must be tested to ensure functionality remains intact in the older environment. Large repositories may require hours for each migration iteration.

Peter’s question: In the last episode, you mentioned a competitor who suggested it would take as much effort to upgrade Uniface 10 as it would to implement their system from scratch. Do you have any further thoughts on that?

Henk: It’s unfortunate when a company resorts to such claims. Rebuilding a complete system would demand far more resources. I’ve seen clients allocate only a fraction of that time for a full upgrade, including organizational preparations, which would also be necessary for a new system.

Peter: From a commercial perspective, how do you explain the value of professional migration support?

Henk: I believe our experience, proven success, and strong relationship with Uniface Lab speak for themselves. We streamline the process in a way that internal teams, who don’t do this daily, cannot easily achieve on their own.

Peter: What can organizations and developers do to make the upgrade easier?

Henk: Two factors are essential:

  1. A Subject Matter Expert who knows the application’s architecture and integrations.
  2. An internal sponsor at a managerial level to ensure organization-wide commitment.

Peter: I know you’ve completed migrations within a few weeks, sometimes on a fixed-price basis, and others have taken up to a year. Why is that?

Henk: Shorter, fixed-price projects are usually repository-only migrations. Full upgrades, involving OS and build environments, are more complex and often require ongoing adjustments.

Peter: Are you able to perform upgrades for multiple organizations simultaneously?

Henk: Yes, and I often do so in practice.

Peter: Are you working on an interesting migration currently, or is that confidential?

Henk: Yes, my current project is interesting due to the repository’s age and size, integration with user-defined 3GL, and a major transition to the cloud. However, confidentiality prevents me from revealing the client’s identity.

Peter: Thank you, Henk. This has been very informative. I hope our listeners found it valuable too.

Peter: I may have our first guest lined up for a future episode—Jan Hengeveld!

Henk: That sounds promising! Are we moving towards a more commercial angle?

Peter: Not exactly, but we will explore the commercial aspects, as they’re relevant to many listeners. Jan Hengeveld, with his expertise, would be perfect for shedding light on these perspectives.

Henk: That sounds fascinating. Can we confirm he’ll join us next time?

Peter: He hasn’t made a final decision yet, but I’m optimistic!

Henk: Then we have only one thing left for our listeners.

Peter: And that is?

Henk: Tune in again next time.

Peter: Exactly! That’s a great conclusion for this episode, where we discussed migration. Key takeaways: a Subject Matter Expert and internal support are crucial, repository migration is best done in iterations, and Henk explained the differences between upgrade, update, and migration.

We realized we need a deeper dive into the technical aspects, so we’re planning a follow-up episode. Thank you all for listening! If you have questions or topics to suggest, please reach out through our website: Unividuals.com.

Related podcast episodes

Podcast topics covered in this episode

Hosts of this episode

(Unividuals)
(Unividuals)