Skip to content

Chapter 3: Object Mapping and Configuration Merge

Phase 2 classified what exists -- every customized BO, workflow, form, report, query, and integration in your environment, categorized by migration action. This chapter tells you what to do with each one. You will generate OM comparisons against the MREF baseline, apply a retain/adopt/merge decision framework to every customized object, and resolve conflicts where both you and IBM changed the same artifact. The chapter is structured as follows: a concept glossary for MREF terminology, the OM tool in the MREF context, the retain/adopt/merge decision framework, conflict resolution patterns, and feature parity analysis.

1. Concept Glossary

MREF introduces terminology changes that affect every subsequent section of this guide and your day-to-day communication with IBM Support. Reference this glossary throughout the migration engagement.

TRIRIGA Term MREF Equivalent What Changed
TRIRIGA Maximo Real Estate and Facilities (MREF) Full product rebrand Verified1
TAS (TRIRIGA Application Suite) MAS (Maximo Application Suite) Suite-level rebrand Verified2
Maximo (the EAM product) Manage Disambiguated from suite name Verified26
Snapshots (UX metadata) Revisions Renamed in platform 3.6+ Verified3
Support & Report tab (Admin Console) Must Gather Tool Admin console rename Verified4
List Manager / Label Manager (Security) Lists / Globalization Manager Security group restructuring Verified5
TRIRIGAMIDDLEWARE.properties TRIRIGA DB (in Admin Console System Manager) File removed; replaced by admin console entry Verified4
SystemReport / CommunityReport (strings) System Report / Community Report (two words) Formatting change in internal strings Likely8
Process Servers OpenShift Pods (automated scaling) Workload distribution restructured Verified6
Agent Tables (AGENT_REGISTRY, AGENT_STARTUP) Pod scaling (tables must be truncated) Agent-based distribution removed Verified6
WebSphere Liberty (manually installed) Embedded Liberty (operator-managed) Deployment model change Verified9
System user (human admin login) Internal service account only Repurposed; human admins use MAS accounts Verified6
Named-user / Enterprise licensing AppPoints (Self-Service/Limited/Base/Premium) Entire licensing model replaced Verified7
TRIRIGA user management MAS Core user management Auth, SSO, lifecycle stripped from product Verified9
Context path (URL parameter) Removed No longer used in MREF URLs Verified8
File system access (full) Persistent dirs only (userfiles/config/log) Containerization constraint Verified9
IBS_SPEC_ASSIGNMENTS table Module Level Association tables Database schema restructured Verified10
Reverse Association flag (queries) Deprecated (forward associations only) Ignored when MLA is active Likely11
Red Hat Marketplace (accelerators) Maximo Accelerators landing page Distribution channel moved Likely23
TRIRIGA Reporting licenses Retired Not available in MREF Verified27

Tip

Bookmark this glossary. Every subsequent section -- and later chapters -- uses MREF terminology.

2. OM Tool in the MREF Context

You know the OM tool from TRIRIGA upgrades. This section covers only what is different when comparing against the MREF baseline -- the mechanics are the same, but the context changes what you see in the reports and how you interpret the results.

Warning

Report 3 generation requires a clean, out-of-the-box TRIRIGA reference environment with the MREF OM package loaded. You cannot run this comparison against a customized environment -- the baseline data will be unreliable. Budget for a separate reference instance in your environment topology.

Report Interpretation Table

All four OM comparison reports are relevant in Phase 3. Phase 2 introduced Reports 1-3 for classification; this section adds the decision lens and introduces Report 4 for post-merge validation.

Report Format Generated From What It Contains MREF-Specific Interpretation Phase 2 Usage Phase 3 Usage
Report 1 CSV Source environment, Object Label Manager query All objects with custom labels (e.g., Acme:1.0) Master inventory of customer customizations Starting inventory of customized artifacts Cross-reference with Report 3 for retain/merge categorization
Report 2 TXT Source environment, custom label detail Exact structural modifications per custom label (field additions, workflow changes, form layout changes) Blueprint of customer's actual development work Understanding scope of each customization Determines merge direction (Report 2 vs Report 3 volume comparison)
Report 3 TXT (tab-delimited) Clean reference environment with MREF OM package loaded What IBM changed in MREF baseline Higher volume than typical TRIRIGA upgrade due to MREF enhancements Classification (Report 1 vs 3 cross-reference) Adopt/merge categorization; merge candidates identified
Report 4 TXT OM upgrade package compared against your development environment after all merges are complete Validation that merges were executed correctly Cross-reference against Report 2: every custom change should now be present on top of the MREF baseline Not used in Phase 2 Post-merge validation; proves custom logic intact alongside IBM enhancements

MREF-Specific Gotchas

  1. Report 3 volume. Expect Report 3 to be significantly larger than in a typical TRIRIGA version upgrade. MREF introduces major baseline enhancements -- AI-driven lease abstraction, cross-suite Manage synchronization, Envizi Connector, dynamic space planning -- which means more IBM changes and a higher conflict rate with your customizations. Verified (no public citation located)

  2. Report 4 validation gaps. Report 4 cannot fully validate workflows or UX web view files. For workflows, use Text Export Selected (.cld files) and an external diff tool. For UX apps, use Download Content For Selected (ZIP with OM/ and System/ folders) and an external HTML diff tool. Verified12

  3. Import Non-Conflicting limitations. The Import Non-Conflicting action (Platform 3.6.0+) can be used after removing merge candidates from the package, but it can leave the environment in an incomplete upgraded state if critical baseline objects are skipped. Use it deliberately, not as a shortcut. Verified13

  4. Environment topology. A clean OOTB reference environment is mandatory for generating Report 3. This is a separate instance from your development environment -- do not attempt in-place comparison. Verified6

Report 4: Post-Merge Validation

After completing your merge decisions and imports, run the OM comparison from the upgrade package against your development environment. This is the same upgrade package used to generate Report 3, but the target is now your post-merge dev environment instead of the clean OOTB reference instance. Cross-reference Report 4 against Report 2: every custom change that Report 2 identified should now be present in your dev environment on top of the new MREF baseline. If an object still shows unexpected differences, that merge was incomplete or applied incorrectly.

Use Report 4 as your primary validation checkpoint, but do not treat it as exhaustive.

Gotcha

Report 4 cannot validate workflow logic or UX web view file content -- it only confirms structural metadata (headers, task counts, component presence). Complement Report 4 with two manual validation steps: (1) Text Export Selected for workflows, comparing .cld files via external diff, and (2) Download Content For Selected for UX apps, comparing OM/ and System/ folder contents via external HTML diff. These are the only reliable methods for confirming workflow and UX merge correctness. Verified28

See Phase 2, Section 2 for OM Reports 1-3 classification usage. See Section 4 below for conflict resolution patterns when handling merge candidates.

3. The Retain/Adopt/Merge Decision Framework

Your Phase 2 inventory classified every customized object. This section provides the decision methodology for determining what happens to each one during MREF migration: retain your version, adopt the IBM baseline, or flag it as a merge candidate requiring manual resolution.

3.1 Universal Decision Tree

Apply this logic to every object in your Phase 2 inventory:

For each object in your Phase 2 inventory:

1. Is the object in Report 1? (Has custom label)
   NO  -> Is it in Report 3? (IBM changed it)
          YES -> ADOPT (import MREF baseline directly)
          NO  -> No action needed (unchanged both sides)
   YES -> Is it in Report 3? (IBM also changed it)
          NO  -> RETAIN (your customization, IBM didn't touch it --
                  OM import will not overwrite)
          YES -> MERGE CANDIDATE (conflict -- go to Section 4)

The logic reduces to three categories:

  • Objects in Report 1 only = Retain. You customized it, IBM did not change it in MREF. The OM import process will not overwrite objects with custom labels that have no baseline conflict. Your customization carries over as-is.
  • Objects in Report 3 only = Adopt. IBM changed it in MREF, you never customized it. Safe to import the MREF baseline directly -- this brings in new functionality with no risk to your work.
  • Objects in both Report 1 AND Report 3 = Merge candidate. Both you and IBM changed the same object. These require manual resolution. Remove them from the import package before running Import Non-Conflicting, then resolve each one individually using the conflict resolution patterns in Section 4.

3.2 Merge Direction Heuristic

For every merge candidate (objects in both Reports 1 and 3), determine which direction minimizes rework:

  • When Report 2 changes < Report 3 changes (IBM made more changes than you): Import the IBM object, then re-apply your custom changes on top. You are working with a smaller delta.
  • When Report 2 changes > Report 3 changes (you made more changes than IBM): Keep your object, then manually apply IBM's changes into it. IBM's delta is the smaller one.

In both directions, apply a new merge label using Object Label Manager to create an auditable trail. Use a naming convention that captures both lineages -- for example, Acme:1.0 (IBM-T:11.6) -- with the Generated From and Merged From fields populated.

Tip

The merge direction heuristic saves time. If IBM restructured a BO significantly and you only added two fields, start from IBM's version. If you built twelve custom tabs on a form and IBM changed two fields, keep yours.

3.3 Artifact-Specific Guidance

The universal decision tree applies to all artifact types, but the merge behavior differs by artifact. These callouts highlight where the standard logic needs adjustment.

Tip

Workflows -- Retain is almost always correct for workflows. They carry over intact to MREF. Only merge if IBM updated a specific workflow you also modified. When merge is necessary, use Text Export Selected (.cld files) and an external diff tool to compare logic -- the OM comparison only shows same/different at the task level.

Warning

Forms, Queries, and Navigation -- These are fully overwritten on import, not field-level merged like BOs. If you have a form in both Report 1 and Report 3, rename or copy your custom version BEFORE import. After import, manually reconcile your copy against the new MREF baseline. See Pattern 2 (Form Layout Collision) in Section 4.

Gotcha

UX Applications -- Importing a UX Application deletes any UX metadata in the target environment related to that Application but NOT included in the import package. Ensure your import package contains ALL UX components you want to keep. If you excluded components during selective merge, re-apply changes immediately after import. See Pattern 6 (UX Application Code Divergence) in Section 4.

Business Objects: BO fields, smart sections, and associations DO merge during import -- the OM tool handles field-level merging. However, field formulas, state family definitions, and BO properties are overwritten, not merged. If you modified any of these, treat the BO as a merge candidate even if the field-level merge is clean. Verified14

3.4 Module-by-Module Processing Strategy

Work through one module at a time rather than attempting to process all customizations across the entire environment simultaneously. This keeps context focused, prevents cross-module confusion, and surfaces reusable patterns early.

Suggested processing order:

  1. Real Estate -- Typically the most customized module; processing it first surfaces patterns you can reuse
  2. Facilities -- Second-highest customization density in most environments
  3. Capital Projects -- Often has complex workflow customizations
  4. Workplace Services -- Reserve, room/desk booking customizations
  5. Sustainability -- Newer module, fewer customizations expected
  6. Custom Modules -- Process last; these are entirely your code with no IBM baseline conflict

This order matches Phase 2's module-level inventory structure. Each module's retain/adopt/merge decisions should be completed and validated before moving to the next.

Tip

Process the module with the most customizations first. Early wins build confidence and surface patterns you can reuse across remaining modules.

3.5 Decision Log Template

Track every retain/adopt/merge decision for client sign-off and post-migration troubleshooting. Copy this template and fill one row per object that requires a decision (skip objects that fall into "no action needed" from the decision tree).

Module Object Type Conflict Pattern Decision Rationale Risk Tested
Real Estate triLease (BO) BO Field Addition Conflict Merge (IBM direction) IBM restructured lease fields for AI abstraction; our 3 custom fields easily re-added Medium No
Real Estate triLeaseForm Form Form Layout Collision Retain (copy + reconcile) 12 custom tabs, IBM only changed 2 fields Low No
Facilities triWorkTask - Route to FM Workflow -- Retain Custom routing logic, IBM did not modify this workflow Low No
Facilities triServiceRequest (BO) BO Field Addition Conflict Merge (customer direction) 15 custom fields vs 2 IBM changes; easier to apply IBM's delta Medium No

The Conflict Pattern column maps directly to the named patterns in Section 4. Leave it blank for straightforward retain/adopt decisions. The Tested column tracks whether the merged object has been validated in the development environment -- update it during Phase 6 testing.

3.6 Anti-Patterns

Warning

Avoid these common mistakes during the decision and import process:

  1. Importing without removing merge candidates. The OM import will overwrite custom logic for objects that appear in both Report 1 and Report 3. You must remove conflict objects from the import package BEFORE running the import. Failure to do so silently destroys your customizations.

  2. Using Import Non-Conflicting as a shortcut. This action skips conflict objects automatically, but it also skips critical baseline objects that may be needed for new MREF functionality. If you use it, review what was skipped and determine whether any skipped objects are required for features you intend to adopt.

  3. Running comparison without a clean reference environment. Report 3 requires a clean, out-of-the-box TRIRIGA instance with the MREF OM package loaded. Running comparison against a customized environment produces unreliable baseline data and leads to incorrect retain/adopt/merge decisions.

Key Takeaway

The decision tree is simple: Report 1 only = retain, Report 3 only = adopt, both = merge candidate. The complexity lives in the merge -- that is what Section 4 covers. Use the merge direction heuristic to minimize rework, process one module at a time, and log every decision for audit and troubleshooting.

4. Conflict Resolution Patterns

When the decision tree in Section 3 identifies a merge candidate (object in both Report 1 and Report 3), resolution follows artifact-specific patterns. This section catalogs the common conflicts with named patterns, what each looks like in OM reports, and how to resolve them.

Tip

Not every conflict maps to a named pattern. When it does not, see the escalation criteria at the end of this section.

Pattern 1: Field Addition Conflict

What it looks like in OM reports: BO appears in both Report 1 (custom label with added fields) and Report 3 (IBM also modified the BO in the MREF baseline).

Why it happens: You added custom fields to a standard BO; IBM also added or modified fields in the same BO for MREF.

Resolution approach: BO fields, smart sections, and associations merge during import -- the OM tool handles field-level merging automatically. Text field sizes are protected (import will not reduce your larger size). However, field formulas, state family definitions, and BO properties do NOT merge -- they are overwritten by the import. If you modified any of these, export your versions before import and re-apply after. Verified29

Risk: Medium

Pattern 2: Form Layout Collision

What it looks like in OM reports: Form objects appear in both Report 1 and Report 3.

Why it happens: You modified form layouts (added tabs, rearranged sections, changed field visibility); IBM also updated forms in the MREF baseline.

Resolution approach: Forms are FULLY OVERWRITTEN by import -- not merged. Before import, rename or copy your custom form to preserve it. After import, manually reconcile your copy against the new MREF baseline form. Apply field requirement (Required) and read-only attributes at the Data Modeler level, not the form level -- Data Modeler settings survive form overwrites. Verified14

Risk: High

Pattern 3: Workflow Logic Divergence

What it looks like in OM reports: Workflow objects flagged as "different" in the OM comparison, but no detail about what changed. The comparison only shows same/different at the task level.

Why it happens: You modified workflow task logic; IBM also modified workflow logic in the MREF baseline.

Resolution approach: Use Text Export Selected to export both versions as .cld text files. Run the two .cld files through an external diff tool to see the actual logic differences. Determine which changes to keep based on business requirements. Reconstruct the merged logic in Workflow Builder. Apply a merge label via Object Label Manager to create an audit trail. Verified15

Risk: High (most labor-intensive pattern)

Pattern 4: Query/Report Overwrite

What it looks like in OM reports: Query or report objects appear in both Report 1 and Report 3.

Why it happens: You modified queries or reports; IBM also updated them in the MREF baseline.

Resolution approach: Queries and reports are fully overwritten by import (same behavior as forms). Rename or copy your custom versions before import. After import, evaluate differences and update your custom copy as needed. Check for reverse association usage in your queries -- reverse associations are deprecated when Module Level Associations (MLA) are active in MREF. Convert any reverse associations to forward associations. Verified16

Risk: Medium

Pattern 5: Navigation Collection Overwrite

What it looks like in OM reports: Navigation items appear in both Report 1 and Report 3.

Why it happens: You customized navigation menus; IBM restructured navigation in the MREF baseline.

Resolution approach: Navigation items are fully overwritten on import. Best practice: create an entirely new navigation collection with your custom items rather than modifying IBM's collections. Remove OOTB tri-prefixed collections from Navigation Builder and add your custom items to the new collection. If your modifications were minimal, note the changes before import and reapply them after. Verified14

Risk: Low

Pattern 6: UX Application Code Divergence

What it looks like in OM reports: UX Application or Web Component flagged as "different" but the comparison only shows same/different for web view files -- no code-level detail.

Why it happens: You modified UX HTML, JavaScript, or CSS; IBM also updated UX code in the MREF baseline.

Resolution approach: Use "Download Content For Selected" to extract a ZIP containing OM/ (source) and System/ (target) folders. Run the extracted files through an external HTML diff tool to identify code-level differences. Manually merge the code changes. Ensure your import package contains ALL UX metadata components you intend to keep -- any UX metadata in the target environment related to that Application but NOT included in the import package is permanently deleted (clean target deletion). Verified17

Risk: High (clean target deletion risk)

Pattern 7: Deprecated Feature Conflict

What it looks like in OM reports: Objects reference features that MREF has deprecated or removed -- reverse associations in queries, Polymer-based UX components, removed system properties.

Why it happens: Your customizations depend on features that MREF has deprecated or structurally changed.

Resolution approach: Identify affected objects using the Feature Parity Analysis in Section 5. For reverse associations, convert to forward associations before or during merge. For Polymer UX components (e.g., legacy triRoomReservation), manually delete the legacy Application, Model-and-View, and Web View records after import -- the OM upgrade package does not auto-delete them. For removed system properties, check the Admin Console for an equivalent setting. Verified18

Risk: Varies (Low to Migration Blocker depending on the deprecated feature)

Escalation Criteria

When to engage IBM Support or the platform team (beyond pattern-based resolution):

  • Object merge produces runtime errors that cannot be traced to a known pattern
  • OM import fails with platform-level errors (not object-label conflicts)
  • Custom BO structural changes conflict with MREF database schema changes (e.g., Module Level Association conversion)
  • Customization Archive interactions with OM-merged objects produce unexpected behavior
  • Combined OMP generation failures when merging multi-version packages

Information to Gather Before Escalating

Prepare these five data points before opening a support case:

  • OM comparison reports (all four: Reports 1-4)
  • Specific object names and labels involved in the conflict
  • Error logs from the server (especially CldFromOMXML warnings)
  • Platform version and Application version of both source and target environments
  • Whether Import Non-Conflicting was used (and if so, which objects were skipped)

Key Takeaway

Seven patterns cover the majority of OM merge conflicts. If your situation does not match a pattern, gather the five data points above and escalate. Do not spend days troubleshooting an unrecognized conflict -- IBM Support has seen it before.

5. Feature Parity Analysis

This section documents what MREF adds, changes, and removes relative to standalone TRIRIGA. Unlike Phase 1's high-level overview of what carries over and what does not, this analysis uses the OM comparison as evidence -- if you see unfamiliar objects in Report 3, this section explains what they are. If you see objects in your inventory that reference deprecated features, this section tells you the impact.

5.1 Features MREF Adds

These capabilities are new in MREF and do not exist in standalone TRIRIGA. They appear in Report 3 as objects your environment does not have. The decision tree correctly categorizes them as "Adopt" -- they are net-new IBM objects with no conflict risk.

Feature Description Impact on Migration Confidence
AI-Driven Lease Abstraction AI tooling for lease document processing New capability; no migration action, optional adoption Verified19
Cross-Suite Integration (Manage sync) Native synchronization between MREF and Manage schemas New capability; requires schema configuration if adopted Verified20
Envizi Connector (ESG/GHG) Sustainability reporting integration New capability; optional adoption Verified21
Maximo Monitor Integration IoT/Wi-Fi sensor data for space utilization New capability; optional adoption Verified22
Microsoft Teams Integration (Reserve) Native Teams video call links in reservations Enhancement to existing Reserve; optional Verified22
Graph API for Exchange (Reserve) Updated Microsoft Exchange integration Enhancement; replaces EWS (mandatory from 11.4) Verified23
Operational Dashboards Unified MAS dashboards with MREF data New capability; optional adoption Likely23
Combined OMP Generation (9.2+) Combine migration packages for multiple app versions Streamlines OM process for large version jumps Likely30

Tip

These new features appear in Report 3 as objects your environment does not have. The decision tree correctly categorizes them as "Adopt" -- they are net-new IBM objects.

5.2 Features MREF Changes

These features exist in standalone TRIRIGA but behave differently in MREF. Each requires a specific migration action.

Feature What Changed Migration Action Confidence
Authentication model Centralized in MAS Core; API keys for HTTP/SOAP inbound Reconfigure all integration auth. See Phase 5. Verified24
User management Stripped from TRIRIGA product, managed in MAS Core Migrate users via User Migration Tool (UMT) Verified31
Licensing AppPoints replaces named-user/Enterprise licensing Run UMT, audit service accounts for tier assignment Verified32
System properties Some now operator-managed (CR/ConfigMap) Map retained vs moved vs removed properties. See Phase 4. Verified9
Workload distribution Pod scaling replaces agent tables Truncate AGENT_REGISTRY and AGENT_STARTUP before DB connect Verified33
Custom Java deployment Immutable containers; no file system drops Migrate to ClassLoader records or Customization Archives. See Phase 5. Verified34
Reverse associations Deprecated when Module Level Associations (MLA) active Audit all custom queries/reports; convert to forward associations Likely35

5.3 Features MREF Removes or Deprecates

These features are removed or deprecated in MREF. Each is categorized by impact to help you quickly assess client risk.

Feature Impact Category Migration Action Confidence
Context path (URL parameter) No Action Needed Update bookmarks and links that reference the old URL format Verified8
TRIRIGAMIDDLEWARE.properties No Action Needed Use Admin Console TRIRIGA DB entry instead Verified8
SystemReport/CommunityReport (one-word strings) No Action Needed Internal string formatting change only; no user action Likely8
Broad file system access Workaround Available Route all file operations to persistent directories (userfiles, config, log) Verified36
Manual agent table management Workaround Available Pod scaling is the automatic replacement; no manual configuration needed Verified37
RMI integration Migration Blocker Rebuild as REST APIs before migration Verified25
TRIRIGA Reporting licenses No Action Needed Licensing absorbed into MAS AppPoints model Verified27
Reverse Association flag (queries) Workaround Available Convert to forward associations; reverse associations via workflow tasks still supported Likely38
Red Hat Marketplace accelerators No Action Needed Available at Maximo Accelerators landing page instead Likely23
Human "System" user login Workaround Available Use MAS admin accounts for human administrator access Verified39

Warning

RMI integration has no MREF equivalent. If your environment uses RMI-based integrations, they must be rebuilt as REST APIs before migration. This is a hard blocker -- do not proceed with migration until RMI dependencies are eliminated.

Tip

Most removals are cosmetic or have direct workarounds. The only Migration Blocker identified is RMI integration. If your Phase 2 integration inventory does not include RMI, this table has no blockers for your environment.

For the high-level view of what carries over and what does not, see Phase 1, Section 2. For custom code adaptation procedures for changed features, see Phase 5.

6. Key Takeaway

Key Takeaway

The OM tool does the heavy lifting -- Reports 1-4 give you the data, the decision tree gives you the logic, and the conflict resolution patterns give you the playbook. Process one module at a time, log every decision, and escalate early when a conflict does not match a known pattern. Your Phase 2 inventory is the input; a completed decision log is the output. Hand the decision log and any unresolved items to Phase 5 (custom code adaptation) and Phase 6 (testing and cutover).

Next: Phase 4 -- Infrastructure and Deployment | Phase 5 -- Custom Code and Integration Adaptation

Sources

  1. Briwo Solutions: IBM MREF; IBM Docs: TRIRIGA Application Suite; IBM MREF FAQ; eCIFM: Early TRIRIGA-to-MREF Lessons ↩

  2. IBM MREF FAQ ↩

  3. IBM Docs: Object Labels and Revisions; IBM Docs: Revisions & Object Label Manager; IBM Docs: Revisions & Object Migration; IBM Docs: Tracking Object Revisions; IBM Docs: UX in Object Migration tool ↩

  4. IBM TRIRIGA Release Notes for 10.5.1 and 3.5.1 ↩↩

  5. IBM TRIRIGA Release Notes for 10.5.1 and 3.5.1; IBM Docs: Revisions & Object Label Manager ↩

  6. eCIFM: Early TRIRIGA-to-MREF Lessons ↩↩↩↩

  7. eCIFM: Early TRIRIGA-to-MREF Lessons; TRIRIGA Product Roadmap Update 2025; IBM SaaS migration deck (Oct 2025, PDF) ↩

  8. IBM Docs: What's changed in MREF ↩↩↩↩↩

  9. eCIFM: Early TRIRIGA-to-MREF Lessons; IBM Docs: What's changed in MREF ↩↩↩↩

  10. IBM TAP Product Overview ↩

  11. IBM Docs: Converting IBS_SPEC_ASSIGNMENTS to MLA; IBM Docs: Query and report performance ↩

  12. IBM Docs: Upgrade Process ↩

  13. IBM TAP Readme ↩

  14. IBM TAP Object Migration User Guide; IBM Docs: Merging object types ↩↩↩

  15. IBM Docs: Application Building for TRIRIGA; IBM Docs: Merge objects; IBM TAP Object Migration User Guide ↩

  16. IBM Docs: Converting IBS_SPEC_ASSIGNMENTS to MLA; IBM Docs: Query and report performance; IBM Docs: TRIRIGA tuning; IBM TAP Object Migration User Guide ↩

  17. IBM Docs: UX in Object Migration tool; IBM TAP Application Upgrade User Guide; IBM Docs: Merge objects; IBM TAP Object Migration User Guide ↩

  18. IBM Docs: Converting IBS_SPEC_ASSIGNMENTS to MLA; IBM TRIRIGA Release Notes for 10.5.1 and 3.5.1; IBM Docs: Building UX Web Applications ↩

  19. IBM MREF FAQ; IBM SWMUG presentation: RE&F Roadmap (PDF); IBM MREF documentation (Feb 2026, PDF) ↩

  20. IBM MREF FAQ; IBM SWMUG presentation: RE&F Roadmap (PDF); IBM MREF FAQ; IBM MAS/TAS Connector ↩

  21. IBM MREF technical content (PDF); IBM Sustainability Software Portfolio Connectors ↩

  22. IBM MREF technical content (PDF); IBM SWMUG presentation: RE&F Roadmap (PDF) ↩↩

  23. IBM SWMUG presentation: RE&F Roadmap (PDF) ↩↩↩↩

  24. TRIRIGA Product Roadmap Update 2025; IBM MREF vs TAS architecture comparison (PDF) ↩

  25. IBM MAS Manage FAQ ↩

  26. IBM MAS Manage FAQ; TRM Group: AppPoints Licensing Explained ↩

  27. IBM Docs: What's changed in MREF; IBM MREF FAQ ↩↩

  28. IBM TAP Application Upgrade User Guide; IBM TAP Object Migration User Guide ↩

  29. IBM TAP Object Migration User Guide; NotebookLM research synthesis on OM tool ↩

  30. IBM TRIRIGA Release Notes for 11.X and 4/5.X ↩

  31. IBM Docs: What's changed in MREF; IBM Docs: Migrating TRIRIGA users and licenses ↩

  32. IBM Docs: Migrating TRIRIGA users and licenses; IBM Partner Enablement deck (June 2025, PDF) ↩

  33. IBM Docs: Migrating the application database; IBM MREF vs TAS architecture comparison (PDF) ↩

  34. IBM Docs: Custom classes and custom tasks; IBM Docs: Adding customizations ↩

  35. IBM Docs: Converting IBS_SPEC_ASSIGNMENTS to MLA; eCIFM: Early TRIRIGA-to-MREF Lessons ↩

  36. eCIFM: Early TRIRIGA-to-MREF Lessons; IBM Docs: Basic configuration ↩

  37. IBM Docs: Migrating the application database; eCIFM: Early TRIRIGA-to-MREF Lessons ↩

  38. IBM Docs: Converting IBS_SPEC_ASSIGNMENTS to MLA ↩

  39. IBM Docs: Migrating the application database; IBM Docs: What's changed in MREF ↩