Chapter 2: Assessment and Customization Inventory¶

Phase 1 identified the complexity drivers -- custom Java outside the ClassLoader pattern, version distance to 11.5/11.6, AES encryption dependencies, and integration posture. This chapter provides the methodology to measure them. You will work through four inventory categories, produce classified templates for each, and hand the results to downstream phases for action.

1. Assessment Workflow¶

The assessment covers four inventory categories, each feeding a different downstream phase. Work them in this order:

Standard Artifacts (biggest volume) -- BOs, workflows, forms, reports, queries, navigation, portals, security groups, UX apps. Use OM tool Reports 1-3 to classify each as standard or customized. Feeds Phase 3 merge decisions.
Custom Java (highest risk) -- ClassLoader records, file system JAR drops, web.xml modifications. Classify each as ClassLoader record or Customization Archive candidate. Feeds Phase 5 repackaging.
Integrations (external dependencies) -- Group by authentication mechanism (API keys, OIDC, AES keystore). Audit AppPoints consumption per service account. Feeds Phase 5 auth migration.
System Properties (cleanup) -- Curated review of TRIRIGAWEB.properties against MREF operator-managed configuration. Feeds Phase 4 property migration.

Tip

Flag-and-park any showstoppers found during the standard artifact pass -- custom Java assessment in Section 3 will determine feasibility gates.

The OM tool's comparison Reports 1-3 are the analytical backbone for standard artifact classification. They tell you what has been customized, what the MREF baseline looks like, and where conflicts exist. But they are classification tools only in this phase.

Warning

Use OM Reports 1-3 for classification only. Retain/adopt/merge decisions belong in Phase 3. Attempting merge decisions during assessment wastes time and risks corrupting your development environment.

2. Standard Artifact Inventory¶

Start at the module level -- Real Estate, Facilities, Capital Projects, Workplace Services, Sustainability, and any custom modules -- then drill into artifact types within each module. The goal is a complete list of every customized object, classified by migration action.

Where to Find Each Artifact Type¶

Artifact Type	Admin Console Location
Business Objects	Tools > Builder Tools > Data Modeler
Workflows (sync and async)	Tools > Builder Tools > Workflow Builder
Forms	Tools > Builder Tools > Form Builder
Reports / Queries	My Reports / System Reports, Report Manager
Named Queries	Report Manager > Named Queries
Navigation Items	Tools > Builder Tools > Navigation Builder
Portals / Dashboards	Tools > Builder Tools > Portal Builder
Security Groups	Tools > Administration > Security Manager
UX Apps	Tools > UX Designers (Application, Model, Web View metadata)
Object Labels	Tools > System Setup > System > Object Label Manager

You do not need to manually audit each builder tool line-by-line. The OM tool does the heavy lifting -- the discovery hints above are for spot-checking and for artifacts the OM tool does not fully cover (UX app code, named queries).

OM Tool Reports for Classification¶

Three of the four OM comparison reports are relevant during assessment. Report 4 (validation) is a Phase 3 concern.

Report 1 (CSV): Lists all objects with custom object labels (e.g., Acme:1.0). If an object has a custom label, it has been touched. This is your starting inventory of customizations. Verified¹
Report 2 (TXT): Detailed changes associated with each custom label in your source environment -- field additions, workflow modifications, form layout changes. Use this to understand the scope of each customization. Verified²
Report 3 (Comparison): Cross-references your source environment against the MREF baseline. Generated by loading the MREF OM package into a clean comparison environment. This tells you whether IBM also changed an object you customized -- which determines merge complexity. Verified³

Tip

Report 1 is your starting point. If an object has a custom label, it has been touched. Report 3 tells you whether the MREF baseline also changed that object -- which determines migration complexity.

Cross-comparison methodology: Compare Report 1 against Report 3 to identify three categories:

Objects in Report 1 only = Pure Custom (your customizations, no MREF baseline conflict)
Objects in Report 3 only = Standard OOTB (IBM changed it, you did not)
Objects in both reports = Hybrid/Conflict (both you and IBM changed it -- requires merge decision in Phase 3)

Three-Tier Classification¶

Every artifact falls into one of three migration actions. Classify each row in your inventory accordingly:

Migration Action	Criteria	What It Means
Carries Over	Standard OOTB objects with no custom labels; no modifications	Transfers via database with no action required
Reconfigure	Objects with minor modifications (added fields, adjusted list queries, layout changes) that may need merge decisions	May require retain/adopt/merge decision in Phase 3
Repackage	Objects tied to custom Java code that must be repackaged for MREF's immutable containers	Requires ClassLoader record or Customization Archive -- see Phase 5

Standard Artifacts Template¶

Copy this table and fill one row per customized artifact discovered:

Module	Artifact Type	Object Name	Object Label	Standard/Custom	Migration Action	Notes
Real Estate	Business Object	triBuilding	Acme:1.0	Custom	Reconfigure	Added 3 custom fields for energy tracking
Facilities	Workflow	triWorkTask - Route to FM	OOTB	Standard	Carries Over	No modifications

Gotcha

OM tool comparison for UX metadata only shows same/different -- it does not provide code-level diffs. Use the Download Content feature and an external diff tool for UX app code comparison. Verified⁴

3. Custom Java Inventory¶

Custom Java is the highest-risk inventory category because it determines whether the migration hits hard technical gates. Every custom JAR, servlet, and file system drop must be classified before you can estimate repackaging effort. The classification you perform here drives the Phase 5 repackaging workstream directly.

Where to Look¶

You need to check four locations. Do not skip any of them.

Location	What You Will Find
Admin Console > Class Loader (Tools > System Setup > System > Class Loader)	ClassLoader records -- custom Java workflow tasks stored as database BLOBs
File system `/lib` directory and WebSphere library paths	Ad-hoc JAR drops with no admin console record (legacy practice)
`web.xml`	Servlet registrations, filter mappings, custom URL patterns
Liberty config directories	Non-standard configuration files, custom features

Warning

Do not skip the file system audit. Legacy administrators frequently dropped JARs directly onto the VM file system. These have no TRIRIGA metadata and will cause ClassNotFoundException failures after MREF deployment. Verified⁵

ClassLoader vs Customization Archive Decision Tree¶

Walk through this decision tree for every custom Java component you discover:

Step 1: Is this a JAR implementing com.tririga.workflow.pub.CustomTask with package naming com.tririga.ps.*, com.tririga.appdev.*, or com.tririga.custom.*?

YES and no web.xml/servlet dependencies --> ClassLoader Record (hot-deployable from database, no container rebuild needed) Verified⁵
YES but also references web.xml or servlet mappings --> Customization Archive (see hybrid JAR edge case below)

Step 2: Does it involve servlets, web.xml modifications, JSP files, or 3rd party library JARs?

YES --> Customization Archive (ZIP mimicking /SMP/maximo/ directory structure, processed during OpenShift pod build) Verified⁶

Step 3: Is it a shell script, database .dbc script, or configuration file?

YES --> Customization Archive

Step 4: Anything found on the file system outside userfiles, config, or log directories?

YES --> Customization Archive (when in doubt, Archive is the safer classification)

Edge Cases¶

Gotcha

Hybrid JARs -- JARs containing both com.tririga.custom workflow task classes AND servlet/filter classes. In legacy TRIRIGA, these worked because the entire file system was mutable. In MREF's immutable containers, only ClassLoader-loaded classes get hot-deployed. Split the JAR: workflow tasks to a ClassLoader record, middleware extensions to a Customization Archive. Verified⁵

Gotcha

Undocumented file system drops -- JARs, fonts, scripts placed directly on the VM with no TRIRIGA metadata. These are invisible to any admin console report. The only way to find them is a manual file system audit of the legacy server.

Tip

3rd party JARs with transitive dependencies: all dependencies must be explicitly included in the Customization Archive. MREF's operator will not resolve Maven/Gradle dependencies at build time. Classify the entire dependency tree. Likely (no public citation located)

Risk Indicators¶

Assign a risk level to each custom Java component based on its classification:

Risk Level	Criteria	Rationale
Low	ClassLoader workflow tasks	Hot-deployable, well-documented migration path, no container rebuild
Medium	3rd party library JARs	Must resolve all transitive dependencies; missing a dependency crashes the pod
High	Servlets, web.xml modifications	Require Customization Archive, operator pod rebuild, most complex migration path

Flag any High-risk items as potential migration blockers for early stakeholder communication.

Custom Java Template¶

Copy this table and fill one row per custom Java component discovered:

Component Name	Type	Package/Path	ClassLoader or Archive	Risk	Dependencies	Migration Action	Notes
EnergyCalcTask	Workflow Task JAR	com.tririga.custom.energy.EnergyCalculator	ClassLoader	Low	TririgaCustomTask.jar	Carries Over (upload to ClassLoader record)	Already uses correct package naming
AcmePortalServlet	Servlet JAR + web.xml	/lib/acme-portal.jar	Archive	High	acme-commons-2.1.jar, log4j-1.2.jar	Repackage (build Customization Archive)	Has 2 transitive deps; must include all in ZIP

Tip

You are classifying here. The actual repackaging procedures -- building ClassLoader records and Customization Archives -- are covered in Phase 5.

Key Takeaway

Every custom Java component must be classified as either a ClassLoader record (workflow tasks, hot-deployable) or a Customization Archive candidate (servlets, web.xml, 3rd party libs, file system drops). When in doubt, classify as Customization Archive -- it is the safer path. Flag any High-risk items as potential migration blockers for early stakeholder communication.

4. Integration Inventory¶

Integrations require inventory by authentication mechanism because each auth type has a distinct migration action in MREF. An HTTP/SOAP integration using basic auth follows a different path than a REST integration using OIDC tokens, which follows a different path than a DataConnect job reading flat files. This section groups integrations by type, maps auth changes, flags licensing impact via AppPoints, and provides a template for recording every external system dependency.

Integration Types and MREF Auth Changes¶

Every integration in your environment falls into one of these types. The "MREF Auth Change" column tells you what breaks or changes on day one:

Integration Type	Legacy Auth	MREF Auth Change	Migration Action
HTTP/SOAP inbound	Basic auth / IP whitelist	API Key required (generated in MAS admin)	Generate API keys, update external callers Verified⁷
REST inbound	Basic auth	API Key OR OIDC Verified⁷	Choose auth method, configure in MAS
REST outbound	Stored credentials	Credentials in OpenShift Secrets	Extract and recreate as Secrets
OSLC	OAuth profiles	OAuth profiles streamlined (single profile for multiple UX apps) Verified (no public citation located)	Review and consolidate OAuth profiles
DataConnect	File system staging tables	Persistent volume (`userfiles` only)	Verify persistent volume config; staging limited to `userfiles` Verified⁸
App Connect / MIF	Middleware-managed	Endpoint URL + cert changes	Update endpoints, trust certificates
RMI	Direct Java calls	Permanently deprecated Verified⁷	Rebuild as REST APIs -- hard gate
File-based (flat file)	File system paths	Persistent volume only	Route to persistent directories

Warning

The AES keystore password MUST be extracted and recreated as an OpenShift Secret BEFORE MREF activation. All encrypted passwords in the database depend on this keystore. If not migrated, integrations with stored credentials will fail immediately. Flag every integration using AES encryption as a pre-activation blocker. See Phase 1, Section 3 and Phase 5 for extraction procedures.

Where to Look¶

You need to check four locations across the application frontend and admin console:

Integration Objects: Tools > System Setup > Integration > Integration Object (Database, File, HTTP Post schemes)
OSLC Resources: Tools > System Setup > Integration > OSLC Resource Manager
OAuth Settings: Tools > System Setup > Integration > OAuth Settings
Agent Manager: Admin Console > Agents (Scheduled agents, workflow agents, DataConnect agent)

Do not rely solely on admin console records. Ask the operations team about middleware connections (App Connect, MIF) and any point-to-point integrations that were configured outside TRIRIGA.

AppPoints Audit¶

In legacy TRIRIGA, integration service accounts had no licensing cost per se -- you paid by named user or enterprise license. In MREF's AppPoints model, every active session consumes AppPoints from a shared pool, and integration service accounts are no exception.

Key rules:

Integration service accounts consume AppPoints concurrently while sessions are active Verified⁹
Tier is determined by the highest-tier application the account has access to -- not the application it actually uses Verified⁹
Reference the AppPoints tier table from Phase 1: Self-Service (0), Limited (5), Base (10), Premium (15)

Gotcha

An integration service account that only updates work orders but has a security group granting access to capital planning consumes 15 Premium AppPoints per concurrent connection instead of 10 Base. Audit security groups and strip unnecessary high-tier module access.

For each integration service account:

Open Security Manager and review the assigned Security Groups
Identify the highest-tier module accessible (use the AppPoints tier definitions from Phase 1)
Determine whether the account actually needs that level of access
If over-provisioned, document the recommended security group change and the AppPoints savings

Integration Template¶

Copy this table and fill one row per integration discovered. The "AES Encrypted?" column flags pre-activation blockers -- any "Yes" entry must be resolved before MREF activation.

Integration Name	Type	Auth Mechanism	Direction	External System	Service Account	AppPoints Tier	AES Encrypted?	Migration Action	Notes
Work Order Sync	HTTP Post	API Key	Outbound	ServiceNow	svc_wo_sync	Base (10)	Yes	Reconfigure (extract AES creds, generate API key)	Pre-activation blocker: AES keystore
Space Data Feed	DataConnect	File-based	Inbound	Archibus CSV export	svc_dataconnect	Limited (5)	No	Reconfigure (verify persistent volume)	Staging dir must be in userfiles/

Tip

For each integration, ask: "What happens to this integration on MREF day one if we do nothing?" The answer determines urgency. Inbound HTTP/SOAP integrations will fail immediately (API key required). Outbound REST with stored credentials will fail if AES keystore is not migrated. DataConnect jobs will fail silently if file paths are not in userfiles.

See Phase 5 for the detailed auth migration procedures per integration type.

5. System Properties Assessment¶

TRIRIGAWEB.properties is the single configuration file most TRIRIGA administrators have customized. In MREF, these settings fall into three categories: some remain in the properties file and behave the same, some move to operator-managed configuration where modifying the properties file has no effect, and some are removed entirely. This section provides a curated reference table for the properties found in 80% of environments and a template for inventorying customer-specific settings.

Three-Status Classification¶

Every TRIRIGAWEB.properties setting in your environment falls into one of these statuses:

Retained: Property still exists in TRIRIGAWEB.properties and behaves the same in MREF. Place it in the persistent config directory and restart the pod to apply.
Moved: Property is now managed via the Operator CR, ConfigMap, or OpenShift Secret. Setting it in TRIRIGAWEB.properties has no effect -- the operator overrides it on reconciliation.
Removed: Property is no longer applicable in MREF. The functionality it controlled has been replaced, deprecated, or moved to the Admin Console UI.

Curated Properties Reference Table¶

This table covers the properties you will encounter in most TRIRIGA environments. It is not exhaustive -- Phase 4 provides the complete property-by-property migration mapping.

Property	Category	MREF Status	Where It Moves	Notes
Workflow agent assignment	Agent Config	Moved	Operator CR (`spec.wfagents` array)	Agent tables truncated; pod scaling replaces
`CLEANUP_AGENT_DELETE_DM_CONTENT`	Agent Config	Retained	--	No change
`REBUILD_HIERARCHIES_ON_CLEANUP`	Agent Config	Retained	--	No change
Reserve SMTP Agent (`EXCHANGE_DOMAIN`, `TRIRIGA_RESERVE_SUB_DOMAIN`)	Agent Config	Moved	Admin Console > Reserve SMTP agent tab	Configure in UI, not properties file
Connection pool max	Database	Moved	Operator CR (`spec.db.maxconnpoolsize`)	Operator manages pool sizing
Db2 `jdbcCollection="NULLIDR1"`	Database	Moved	`server.xml`	Liberty config, not properties
`CACHE_LOAD_SIZE_FOR_ORACLE`	Database	Removed	--	Moved to Admin Console Verified¹⁰
HTTP security headers (`X-Frame-Options`, CSP, HSTS, `X-Content-Type-Options`, `X-XSS-Protection`, `Cache-Control`)	Security	Retained	--	Still configured in properties
AES encryption keystore password	Security	Moved	OpenShift Secret (`vault_secret` in Tririga CRD)	Pre-activation hard gate Verified¹¹
`FRONT_END_SERVER` / `EXTERNAL_FRONT_END_SERVER`	Security	Retained	--	Update URLs for MREF endpoint
`SSO_SINGLE_SIGN_OUT_REDIRECT_URL`	SSO/Login	Retained	--	Update URL for MREF
`ALTERNATE_UX_LOGIN_VIEW`	SSO/Login	Removed	--	Use `ALTERNATE_INDEX_HTML` instead Verified¹²
`LOGIN_PAGE_RESOURCE_LIST`	SSO/Login	Retained	--	No change
`SESSION_WARNING_ENABLED`	SSO/Login	Retained	--	No change
`mail.smtp.port`	SMTP	Retained	--	Defaults to 25 if invalid
`EXCHANGE_GRAPH_EVENT_CONSOLIDATION_INTERVAL`	SMTP	Retained	--	Graph API environments
`ENHANCED_RECORD_RENDER_MODE`	UI/Reporting	Retained	--	Default TRUE (Carbon styling)
`REPORT_CASE_SENSITIVE`, `ENABLE_ACCENT_INSENSITIVE`	UI/Reporting	Retained	--	No change
`SHOW_ZEROS_IN_NUMBER_FIELDS`	UI/Reporting	Retained	--	No change
`AVAILABILITY_SECTION_ROW_LIMIT`	UI/Reporting	Removed	--	UX pagination replaces it Verified¹³
Routing timeouts	Routing	Moved	OpenShift route annotations / CR (`spec.rt.timeout`)	Infrastructure-level config
SLS host/port	License Service	Moved	CR (read-only in Admin Console)	MAS manages licensing
`SLS_EXPIRY_NUM_DAYS_WARNING`	Licensing	Retained	--	No change

Warning

Properties with "Moved" status are managed by the MREF operator. Setting them in TRIRIGAWEB.properties will be overridden on pod restart. Modify only via the Operator CR or Admin Console as indicated in the "Where It Moves" column.

Tip

Export your current TRIRIGAWEB.properties file and diff it against a vanilla TRIRIGA install of the same version. Any delta is a candidate for this inventory.

System Properties Template¶

Copy this table and fill one row per customer-modified property:

Property	Category	Current Value	MREF Status	Migration Action	Notes
`FRONT_END_SERVER`	Security	https://tririga.acme.com	Retained	Update URL to MREF endpoint	Verify DNS change with network team
Connection pool max	Database	150	Moved	Set in Operator CR `spec.db.maxconnpoolsize`	Current value may need tuning for pod architecture

For each property, the migration action depends on the MREF status:

Retained: Verify the current value is still appropriate for MREF (e.g., update URLs), place in persistent config directory.
Moved: Document the current value, then set it via the operator mechanism listed in "Where It Moves." Do not set in properties file.
Removed: Document the current value for reference, then remove from your properties file. Check if an Admin Console equivalent exists.

This curated list covers properties in most environments. Phase 4 provides the complete property-by-property migration mapping with operator CR field references.

6. Chapter Summary and Key Takeaway¶

This chapter delivered four inventory categories, each with a classification framework and a working template:

Standard Artifacts (Section 2) -- Classified via OM Reports 1-3 into Carries Over / Reconfigure / Repackage. Template feeds Phase 3 merge decisions.
Custom Java (Section 3) -- Classified via decision tree as ClassLoader record or Customization Archive. Risk-rated Low / Medium / High. Template feeds Phase 5 repackaging.
Integrations (Section 4) -- Grouped by auth mechanism with MREF auth changes mapped per type. AppPoints audit per service account. Template feeds Phase 5 auth migration.
System Properties (Section 5) -- Classified as Retained / Moved / Removed against MREF operator configuration. Template feeds Phase 4 property migration.

Key Takeaway

A complete MREF migration assessment covers four inventory categories in sequence: (1) standard artifacts classified via OM Reports 1-3, (2) custom Java classified as ClassLoader records or Customization Archives, (3) integrations grouped by auth type with AppPoints audit, and (4) system properties classified as Retained/Moved/Removed. The templates in this chapter are your working documents -- copy them, fill them in, and carry the completed inventory into Phase 3 (OM merge decisions), Phase 4 (infrastructure setup), and Phase 5 (custom code repackaging and auth migration). Flag AES keystore migration and High-risk custom Java items as pre-activation blockers early.

Sources¶

IBM TAP Application Upgrade User Guide; IBM Docs: Upgrade Process; IBM Docs: Upgrade preparation ↩
IBM TAP Application Upgrade User Guide; IBM Docs: Merge objects; IBM Docs: Revisions & Object Label Manager; IBM Docs: Upgrade Process; IBM Docs: Upgrade preparation ↩
NotebookLM research synthesis on OM tool ↩
IBM TAP Application Upgrade User Guide; IBM Docs: Merge objects; IBM TAP Object Migration User Guide; IBM Docs: Revisions & Object Migration; NotebookLM research synthesis on OM tool; IBM Docs: Upgrade preparation; IBM Docs: UX in Object Migration tool ↩
eCIFM: Early TRIRIGA-to-MREF Lessons ↩↩↩
TRM Group: Customization Archive; IBM MAS Manage FAQ; IBM Docs: Migrating customizations using customization archives; eCIFM: Early TRIRIGA-to-MREF Lessons ↩
IBM MAS Manage FAQ ↩↩↩
IBM Docs: What's changed in MREF; IBM Docs: System properties; eCIFM: Early TRIRIGA-to-MREF Lessons ↩
IBM Partner Enablement deck (June 2025, PDF) ↩↩
IBM TRIRIGA Release Notes for 11.6 and 5.0 ↩
IBM MAS ansible-devops: suite_app_config role ↩
IBM TRIRIGA Release Notes for 11.0 and 4.0 ↩
IBM TRIRIGA Release Notes for 11.3 and 4.3 ↩