The most positive thing I can think of is that the “replace current systems” project lets us see how the current solution the customer has, has grown by accretion over the years, and has many tight dependencies which they don’t realise. The “preparation” part of the project, which is basically “document what the customer has, so that we’ll be able to replicate the important parts of it” is showing the customer how much they don’t know about their system.
There are periodic scripts, and files transferred between machines, which tie together the many disparate parts of the customer systems — at least a part of the complexity is due to the customer having grown by acquisition more than once, and having the new system changed as little as possible (because it worked) but still needing to fit in to the corporate standards.
We (and the customer) can see that with Monolith, the number of different technologies drops significantly. There are still multiple integrations with the non-monitoring systems; but they are all consistent in the style of “talk to Monolith”, rather than there being very different things for talking to different parts of the current monitoring systems.
As the project progresses, the details of what is no longer necessary, and what will remain, should become clearer — and should be much more straightforward to document, for the next time a migration happens (if only to a new DR-system)