Idea: Automated Migration Manager
Create a new application within the Migration Manager module to support tracking of system configuration changes during development.
Functionality Overview:
Enable Tracking either via System Property or Admin Module or single page app to configure migrations tracking:
- Introduce a system property or an option within the Administration module to enable/disable the System Configuration Change Tracker. Or design a single page application where migration tracking, artifact generations naming conventions if desired, endpoint where artifacts need to be delivered can be configured.
- When enabled, the system will begin tracking changes across various configuration components.
Tracked Configuration Areas Include:
- Application Designer and all related configuration tables
- Conditional UI Expressions
- Security UI Conditions (Attributes, Objects)
- Integration configurations
- Automation Scripts
- Workflow changes
- Database configurations
- Reports
- Security Groups
- Global configurations
Developer Workflow:
- Before starting development, the developer enables the tracker.
- All configuration changes made during this period are logged.
- Once development is complete, the developer disables the tracker.
New Application: “Migration Artifacts”:
- This application will be added under the Migration Manager module.
- It will display two sections:
-
Changes by the current user (logged-in developer)
-
Changes by other users during the same time frame
- Developer will review and finalize(select/ignore/deselect)
- Can enter JIRA ID and/or Sprint and/or Tracker ID and/or EPIC ID.
- Output - JSON or XML. XML can be default.
- This view helps identify conflicting changes and encourages collaboration and communication among developers.
Migration Artifacts Finalization and Delivery Process
The developer will begin by reviewing the system configurations they have performed. Once the review is complete, they will finalize the changes within the Migration Artifacts application. This is done by updating the status of the corresponding record (identified by the Migration Tracker ID) to Final.
Upon finalization, the system will utilize the existing Migration Manager object structures—specifically, the Publish Channels—to export all necessary artifacts. There where we can use agentic AI or we need to build logic. These artifacts will be exported in the correct order of dependency and sequence. The output format will be either JSON or XML, with XML set as the default.
Depending on the configuration:
- Artifacts will be written to the local drive, or configured endpoint.
- If a valid endpoint is provided, they will be delivered to the appropriate GitHub or version control branch and location.
This delivery process will then trigger the local DevOps toolchain, initiating:
- A check-in request, and
-
Approval notifications to the configured stakeholders.
I’d be happy to discuss any part of this process in more detail if needed.
Artifact Import Process into Maximo
Just as artifacts are exported from Maximo, they can also be imported using the Object Structure service or Enterprise Services (ES), based on the Migration Manager’s Managed Object Structures (MOS) or their collections.
The DevOps tool is responsible for distributing these artifacts to the target environment. Once delivered, the import can be handled in one of two ways:
- A scheduled job in the target environment can automatically import the artifacts once received from repository, or
- The DevOps tool itself can perform the import Object Structure-based REST API calls. We can enabled REST call tracking if necessary.
