Cloud migration wave planning often looks sensible on paper, until execution exposes the dependencies nobody fully mapped.

In the latest post in my Waltz-based cloud migration series, I look at why migration waves should not be built only around team preference, application priority, or technical readiness.

Those inputs matter, but they do not show the structure of the estate. The real question is dependency-aware sequencing:

• Can this application move independently?
• What must move before it?
• What must move with it?
• Who is affected downstream?
• Which bridges are needed during the hybrid period?

Where are the hidden risks in shared databases, batch jobs, APIs, scheduler dependencies, network flows, and cross-jurisdictional data movement?

Using Waltz, dependency mapping turns those questions into a navigable architecture model. Applications, logical flows, physical flows, interfaces, shared infrastructure, ownership, data classifications, and regulatory context can be connected and reasoned over.

The article also explores how AI agents can work over the Waltz graph to make migration planning more defensible at portfolio scale. AI Agents can surface discrepancies between evidence sources, identify structural risks, recommend wave options against stated objectives, and provide role-specific insights for architects, CTOs, CIOs, and governance teams.

The key point: AI agents do not replace architectural judgement. They make architectural judgement enforceable at scale.

A good migration plan is not just a list of applications. It is a sequenced traversal of an architecture model, supported by evidence, dependency visibility, and continuous challenge.

That is the difference between a wave plan that looks reasonable in PowerPoint and one that survives contact with execution.

Read the full article on cloudhpc.news

#CloudMigration #EnterpriseArchitecture #Waltz #AI #MigrationPlanning #ApplicationPortfolioManagement #DependencyMapping #CloudTransformation #ArchitectureGovernance

AI and machine learning have become almost unavoidable in cloud migration conversations, but where do they genuinely add value, and where do they risk becoming a distraction?

In this fourth article in my Waltz-based cloud migration series, I look at how AI and ML can support architecture-led migration planning without replacing the human judgement that makes the model defensible.

The key point: AI does not remove the architecture problem. It reduces the cost of building and maintaining the architecture view.

Used well, AI can help with:

• First-pass readiness assessments
• Dependency extraction
• Anomaly detection
• Natural-language querying
• Migration artefact generation

Used badly, it creates confident-sounding outputs with no evidence trail, no accountability, and no governance value.

The right question is not “what can AI do for cloud migration?”

It is: “what does the migration programme need to do well, and where can AI accelerate that work without weakening the governance behind it?”

Read the full article: Where AI and Machine Learning Fit in Waltz-Based Cloud Migration Planning

#EnterpriseArchitecture #CloudMigration #AI #MachineLearning #GenerativeAI #CloudStrategy #DigitalTransformation #ApplicationPortfolioManagement #ArchitectureGovernance #DataDrivenDecisionMaking #Waltz #TechnologyStrategy

Cloud migration programmes usually start with one question: which applications are ready to move?

It rarely has a simple answer.

An application can be technically pristine but regulatorily blocked. Business-critical but operationally fragile. Cloud-ready but close to retirement. A single “ready/not ready” score hides exactly the distinctions you need to make a migration plan you can defend.

Our latest post sets out a practical readiness model built in Waltz, scoring applications across six dimensions: technical, operational, business, lifecycle, dependency, and regulatory. Mapping the result to an eight-value rating scheme that points directly to a treatment: rehost, replatform, refactor, replace, retain, or retire.

The aim is not another framework. It is a model that helps you:

• Separate strong migration candidates from blockers
• Surface low-ROI applications
• Sequence migration waves on evidence rather than opinion

Read the full article on here.

#CloudMigration #EnterpriseArchitecture #Waltz

But in many organisations, the real blocker is not the cloud platform. It is the lack of visibility across the application estate.

Before deciding what to move, where to host it, or how to sequence migration waves, teams need to understand:

• Which applications exist
• Who owns them
• How critical they are to the business
• What condition they are in
• What data they use
• Which systems they depend on
• What regulatory or jurisdictional constraints apply

Without that architecture context, migration planning can quickly become spreadsheet-led, subjective, and risky.

See this follow-on article to the HMx Labs case study, we explore why successful cloud migration needs enterprise architecture before infrastructure, and how Waltz can help organisations build the evidence-based decision model needed to migrate with confidence.

Because you cannot migrate what you do not understand.

And you cannot govern what you cannot see.

Read the full article here:

Why cloud migration needs enterprise architecture before infrastructure

Related case study:

Cloud migration case study with Waltz (HMx Labs)

Waltz 1.48 (late March 2023) introduces several new features and some important fixes.

Screencast

This 10 minute screencast gives a quick overview of recent changes in 1.48 (and a few releases before that).

Topics covered:

Report Grids

Report grids have been improved, this screencast covers:

• Cloning (copying existing grids)
• Derived Columns (computing cells from other values)
• Filter groups (saving the results of preset filters)

Assessments

Assessments have been extended to support multi-valued results.
The screencast give a quick overview of how they work and how they are configured.

Legal Entities

Allows linking applications to Legal Entities (i.e. via a Controlling Legal Entity Relationship). The screencast covers:

• Intro to Legal Entity Support
• Navigation
• Bulk loading

Other

• Waltz now allows users to view historic costs associated with groups of applications.
• Assessment overview widgets
• Discussion of improvements to the permission framework

You may also be interested in checking out the complete Waltz playlist on YouTube.

Each commit represents a small step on our 7 year journey from project inception to where we are now.

Some highlights along the way include:

• 50+ releases
• Over 50K users using Waltz in a production setting
• Placing the project under the FINOS organisation
• Many new features and enhancements

We would like to thank all those who have contributed to Waltz, either directly through code, via issues raised or just through reaching out to our team and giving us feedback.

Looking forward to see what the next 10K commits will bring!

Using Solidatus, you can quickly create data blueprints that map how your data flows, and how it’s affected, as it moves around your systems, both now and at other points in time.

By revealing hidden opportunities, threats, and the impact of change, a Solidatus lineage blueprint delivers clarity and an enriched understanding of your data ecosystem, so you can optimize your infrastructure, operate more efficiently, and minimize risk.

Howard Guess has taken the Waltz sample data and imported it into a Solidatus instance.

The instance that Howard has set up is available at on a Solidatus demo instance.

Over the course of 20 minutes, Mark Guerriero takes us on a tour of Waltz features and gives valuable insights and tips on how Waltz can be used in your enterprise.

Topics covered:

• Homepage
• Actions (surveys and attestations)
• Viewpoints (org units, taxonomies)
• Application overviews
  • Assessments
  • Attestations
  • Change Initiatives
  • Bookmarks
  • Costs
  • Data Flows
  • Indicators / Stats
  • People
  • Ratings
  • Technology (servers, databases, software)
  • Changes
• Aggregate Views
  • Org Units
  • Taxonomies

You may also be interested in checking out the complete Waltz playlist on YouTube.

A large part of the recent 1.40 release of Waltz was focused around Report Grids. Notable enhancements are:

• support for Change Initiatives,
• app group / data type / metadata column support
• improved filtering and sharing grids with other users

The screencast below gives an overview of grids; how to use them and how to create them.

You may also be interested in checking out the complete Waltz playlist on YouTube.

We’ve recently been focussed on making Waltz more welcoming to newcomers. Part of that has been through enhancing our getting-started processes with the aid of some fantastic contributions from the Waltz community. In particular:

• Docker images are now published as part of each release via GitHub actions. Thanks to Ljubo Nikolic for this great contribution
• We are working with Canonical to offer Waltz as a JuJu Charm. See the working group and this sub-project for more information

However, in this post we wish to focus on how we are improving our documentation and taking a look at some database related process enhancements.

Database documentation

Liquibase

Beginning in Waltz 1.40 we are adding table and columns level documentation to our database definitions. To add this documentation we will be using two features of Liquibase:

• Table remarks - sets table level documentation
• Column remarks - sets column level documentation

An example of what this looks like for a single table (e.g. entity_hierarchy) is shown below:

Liquibase transforms these commands to the appropriate dbms specific statements. These statements can be written to a DDL script or applied directly to the database. After applying these changes we can see the documentation is now available:

jOOQ Codegen

One unexpected benefit of documenting our database objects is that jOOQ is taking the table and column docs and including them in the generated code.

As you can see this will be a great help in the dev process, especially when dealing wit less frequently used tables and columns.

Multi Vendor Database migration support

The above screenshots were taken whilst working on the issue: Entity Hierarchy: show level of both ancestor and descendant node #5916. This issue adds a new (non-nullable) column to our entity hierarchy table to represent the level of the descendant node. We wished to ensure that Waltz correctly updates this column for any pre-existing data. The update is performed by a Liquibase task which can run arbitrary sql. However, the syntax of the update statements varies between database vendors so we need a few variants of the statement (the appropriate variant is selected by Liquibase via the dbms attribute on changesets).

jOOQ Translate

Luckily the jOOQ website has a superb page which translates SQL statement written in one dialect to another. Keen to give this a try we wrote the migration script for Postgres (1) and requested a translation to SQL Server (2). We quickly tested the resultant statement to ensure it worked and included it in our liquibase script.

We will definitely be using this feature again as it saves so much effort. As we are heavy users of jOOQ within Waltz we have huge confidence in the ability of this tool to generate correct output even for complex statements.

Conclusion

We hope this has shown you how we are making steps to improve our development process by improving our documentation and streamlining our database migration script authoring. If you have any questions reach out to us via our GitHub issues page.