Maximo

Maximo

Come for answers, stay for best practices. All we're missing is you.

 View Only
  • 1.  IBM Maximo Migration Manager

    Posted Wed April 16, 2025 09:57 AM

    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
    ------------------------------


  • 2.  RE: IBM Maximo Migration Manager

    Posted Wed April 16, 2025 01:41 PM

    Hi Arturs,

    The migration manager is meant for moving configurations between environments, like application designer changes, database configurations, automation scripts, conditional expressions etc. It is not meant for moving transactional data.

    If you want to move transactional data like assets, locations, work orders, I would say you can use the MIF (Maximo Integration Framework) or the MXLoader from @Bruno Portaluri




    ------------------------------
    Stefan Hoffmanns
    ------------------------------



  • 3.  RE: IBM Maximo Migration Manager

    Posted Wed April 16, 2025 01:46 PM

    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
    ------------------------------



  • 4.  RE: IBM Maximo Migration Manager

    Posted Thu April 17, 2025 01:50 AM
    Edited by Arthur G Thu April 17, 2025 01:51 AM

    @Jason VenHuizen

    In our organization, any changes made across different Maximo environments are also sent to a GIT repository to track configuration history and versions, but without further deployment to the other environmnets.

    That said, in practice, most of the actual configuration work is done directly in the DEV environment. For example, we configure a new feature or make some changes in DEV, test that it works as expected, and then manually recreate the same configuration in UAT and later in PROD.

    This manual recreation process takes quite a bit of time and introduces a risk of human error, especially when dealing with many small configuration items or conditional setups. So we're currently looking into ways to make this more efficient, and that's why I started investigating what Migration Manager can realistically do for us - or if we should focus more on declarative DevOps approaches like you described in your blog post.

    Thanks for the insights - much appreciated!



    ------------------------------
    Arturs G
    ------------------------------



  • 5.  RE: IBM Maximo Migration Manager

    Posted Thu April 17, 2025 01:58 AM

    @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
    ------------------------------



  • 6.  RE: IBM Maximo Migration Manager

    Posted Thu April 17, 2025 08:27 AM

    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
    ------------------------------



  • 7.  RE: IBM Maximo Migration Manager

    Posted Tue April 22, 2025 03:42 AM

    Hi Stefan,

    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!

    Best regards,



    ------------------------------
    Arturs G
    ------------------------------