Thanks for the insight! We're IT enthusiasts working to make IBM Maximo more user-friendly for our organization. Your advice on refreshing Acceptance before releases is valuable, and the SQL script tip is noted - very helpful!
Original Message:
Sent: Thu April 17, 2025 08:26 AM
From: Stefan Hoffmanns
Subject: IBM Maximo Migration Manager
Hi Arturs,
A best practice approach could be to perform a database refresh from Production to Acceptance before each production release. This way, you have the most recent data in the Acceptance environment, allowing you to execute the release as if it were in Production and also for key-users to validate against production data in Acceptance. We do this for every major release (once every three or four months). The development and test environments are refreshed once a year.
Performing a database refresh is fairly straightforward; the important part is to run a SQL refresh script afterward to update environment-specific variables.
------------------------------
Stefan Hoffmanns
Original Message:
Sent: Thu April 17, 2025 01:57 AM
From: Arturs G
Subject: IBM Maximo Migration Manager
@Stefan Hoffmanns,
Thanks for the clarification - that helps!
Just to follow up: so if, for example, someone changes asset data directly in PROD - such as updating the manufacturer, vendor, location, or asset specifications - do you typically use MxLoader to export and re-import that data into UAT and TEST environments to keep them somewhat in sync?
Or do you have some automated SQL scripts or ETL-type processes that periodically copy changed transactional data (like once a week) from PROD to UAT/TEST?
I understand the environments shouldn't be 100% identical all the time, but it's helpful for testing and troubleshooting to have fairly accurate data in non-PROD environments. So I'm curious how others are managing this part in practice.
Thanks again!
------------------------------
Arturs G
Original Message:
Sent: Wed April 16, 2025 01:45 PM
From: Jason VenHuizen
Subject: IBM Maximo Migration Manager
Arturs,
Migration Manager is primarily intended to move configurations from one Maximo instance to another. With that said, I think that this is fundamentally the wrong approach and is an undisciplined and frankly bad way to manage configurations.
This is because this approach infers what has changed by selectively extracting from one environment and apply that to another. If what is in the source environment is misconfigured or your scope of extract is overly wide or something changes from the point in time you make the change to the time you extract it, you end up with unexpected / undesirable results.
There is also the problem that you have no source of truth in that situation. Is your Development environment really the source of truth for configurations? Do you check in your migration manager packages to source control? How do you know that you only extract just what you wanted and nothing more or that it wasn't changed?
In my opinion it is absolutely critical to declare your configurations and not infer them from an extract. I wrote a whole blog post on it.
https://www.sharptree.io/blog/2023/2023-11-07-devops-deploy/
I happen to have strong opinions on this and others may disagree, but if you have any questions feel free to reach out.
Regards,
Jason
------------------------------
Jason VenHuizen
Sharptree
https://sharptree.io
https://opqo.io
Original Message:
Sent: Wed April 16, 2025 09:56 AM
From: Arturs G
Subject: IBM Maximo Migration Manager
Hi everyone,
I'm currently exploring the capabilities of IBM Maximo Migration Manager, and I have a few questions about what exactly this tool can and can't do.
I understand it's mainly used for moving configuration changes between environments (like from DEV to TEST or PROD), but I'm wondering:
Can it also copy actual data, like asset records or asset specifications, from one environment to another?
For example, if I have a group of assets in DEV with detailed specifications, can I use Migration Manager to export them and import them into TEST?
Or is it only meant for moving configurations like domains, workflows, application changes, etc.?
I'd really appreciate it if someone could clarify the scope of what Migration Manager is designed for - and maybe share how you handle moving sample data or master data between Maximo environments in your organization.
Thanks in advance!
------------------------------
Arturs G
------------------------------