The Silent Customization Killer: AWS SDK for Java v1 to v2 in Maximo Manage

Category: Integrations & Architecture | Maximo Insider | September 24, 2026

There is a class of production incident that is uniquely unpleasant in enterprise asset management. It is not the outage with a stack trace pointing at a failing component. It is not the database corruption with a clear recovery plan. It is the change that arrives inside a routine patch, passes every smoke test, and then breaks one specific customization three weeks later when a seasonal job fires for the first time. Nobody connected the patch to the failure because the patch notes said the upgrade was internal.

That is precisely the shape of IBM's Maximo Manage AWS SDK for Java migration. On August 25, 2026, IBM published a support announcement stating that Maximo Manage is upgrading its bundled AWS SDK for Java from v1.x to v2.x, moving to software.amazon.awssdk version 2.41.34. Amazon ended support for AWS SDK for Java v1.x on December 31, 2025, so the migration itself is overdue housekeeping on IBM's part. The consequence, however, is not housekeeping at all. Version 2 of the AWS SDK uses a completely different package namespace and a different API surface from version 1. Three JARs are being removed. IBM states plainly that any custom scripts, automation, or Java extensions that directly import classes from com.amazonaws.* will stop working after the fix pack containing this change is applied.

This is the compounding-risk story of this particular support cycle. Estates are applying the exact patch releases that carry this change in order to close their Maximo 7.6.1.x exposure before extended support ends on September 30, 2026. The delivery vehicles are Maximo 9.0.29 Patch Release, 9.1.21 Patch Release, 9.2.2 Patch Release, and the 9.3 September Feature Channel. A modernization patch and a code-breaking dependency change are arriving in the same box, and the second one is documented in a support page that most administrators applying a patch release will never read.

This article is about what is actually changing, what breaks, why it is easy to miss, and how to find out whether you are exposed before your first seasonal integration job fails silently in a scheduler log.

What Exactly Is Being Removed, and What Replaces It

The removal list is short and specific, which is fortunate because it means exposure can be scoped precisely. Three JARs are being dropped from the Maximo Manage distribution.

The first is aws-java-sdk-s3-1.12.651.jar. This JAR carries the v1 com.amazonaws package contents for Amazon S3: the AmazonS3 interface, the AmazonS3Client class, and the entire S3 model class hierarchy that sits alongside them. Any Maximo customization that reads a document from S3, writes an attachment to S3, generates a pre-signed URL, or manages bucket lifecycle will reference these classes directly.

The second is aws-java-sdk-core-1.12.651.jar. This is the more insidious removal because core classes are used far more widely than service clients. It carries BasicAWSCredentials and AWSStaticCredentialsProvider, the ClientConfiguration class, and the v1 request signing machinery. Code that never touches S3 directly can still import from this JAR simply to authenticate against a KMS endpoint, sign an SQS request, or configure timeouts on any v1 client.

The third is aws-java-sdk-kms-1.12.651.jar, which carries the v1 AWS KMS client. Key management matters in Maximo estates that encrypt attachment payloads, protect integration credentials, or satisfy an internal control that says data at rest must be envelope-encrypted.

Against those three removals, IBM adds a substantially larger set of version 2.41.34 artifacts: sdk-core, aws-core, s3, kms, auth, identity-spi, profiles, http-auth along with its spi, aws, and aws-eventstream siblings, apache-client, netty-nio-client, and http-client-spi. The count of added JARs is larger than the count of removed ones, which is exactly the sort of detail that leads an administrator to conclude the change is additive and therefore safe.

It is not additive. Version 2 lives under the software.amazon.awssdk namespace. Migration is not a classpath swap where the old import resolves to a new implementation. It is a source-level rewrite.

Several differences matter concretely for anyone porting code. Client construction in v2 is done through builders on an interface rather than through a concrete client class, so new AmazonS3Client(credentials) has no direct equivalent. Configuration in v2 is set either on the builder or through system properties, and the v1 ClientConfiguration type disappears entirely. Credential provision in v2 flows through AwsCredentialsProvider implementations such as StaticCredentialsProvider and DefaultCredentialsProvider, and the v1 chain is gone. Error handling changes shape as well: v2 clients throw service-specific exception types that implement a common AwsServiceException interface, so v1 catch blocks that expected AmazonServiceException with getErrorCode() behavior will not compile against the new types. Response objects in v2 are immutable and largely built through builders, so v1 mutation patterns such as PutObjectRequest.setKey() are removed.

None of this is exotic. It is the standard cost of a major SDK version boundary. It becomes a Maximo problem because the affected code lives inside automation scripts and Java extensions that were written years ago by people who have since changed roles, and because the upgrade arrives unannounced in a patch that nobody associates with their customizations.

Who Is Actually Exposed: Four Categories of Code That Break

IBM's own impact statement names four affected component categories. Reading them as a checklist is the fastest way to scope your exposure, because each one maps to a different place in your estate that you would search.

The first is custom Java classes and extensions. This includes compiled customization deployed into the Maximo Manage classpath, custom MBO code, custom business objects with Java implementations, and interceptors or listeners registered against Maximo business logic. If any of those compiled artifacts imports com.amazonaws.*, it will fail to load or fail at first invocation depending on how the classloader encounters it. Because these are compiled, the breakage is binary: the class does not link against a missing package.

The second is Maximo Automation Scripts that invoke AWS SDK classes. Automation scripts run on the Maximo JVM and can reach whatever is on the classpath. It is common in estates that have moved attachments or integration payloads to object storage to have a script that constructs a v1 S3 client and calls putObject to stage a document before a Maximo record references it. That script will throw a NoClassDefFoundError or a script-level class resolution failure. Because automation scripts are interpreted, the failure surfaces at the moment the script executes rather than at server startup, which is the worst possible time to discover it.

The third is standalone utilities and integrations packaged with MAS. Build pipelines, deployment automation, migration tooling, and any self-contained Java application that a team packaged to run alongside Maximo and that was built against the v1 SDK sit in this category. These frequently live in a build server or a separate container rather than in the Maximo application itself, which means they are often outside the blast radius that a Maximo administrator is thinking about when they read a Maximo patch note.

The fourth is third-party custom solutions and add-ons that reference com.amazonaws.*. IBM is explicit that industry solutions and add-ons must be upgraded to corresponding supported versions in lockstep with the patch. This is the category that creates the most anxiety, correctly. If your organization runs a partner-authored solution that touches S3 or KMS, the timeline is not entirely yours. You need a supported version from the vendor, and you need it aligned with your own patch schedule, and the vendor's release calendar may not match your maintenance window.

One further note on sequencing. If you have both IBM-maintained customization and vendor add-ons, patching Maximo first and waiting on the vendor product creates an interval in which the vendor's code is running against a classpath that no longer contains its dependencies. That interval is a production incident waiting to be scheduled. The correct posture is to obtain vendor confirmation of v2 compatibility before the patch window, and to defer the patch if you cannot.

Why the Timing Is So Unforgiving This Cycle

In a normal year, this migration would be an annoyance scheduled into a quiet quarter. This year it lands inside the most compressed Maximo maintenance window in recent memory.

Extended support for the Maximo 7.6.1.x line ends on September 30, 2026. That has driven an enormous volume of estates toward the modern MAS release lines in a short span. Whether an organization is accelerating a full migration, buying formal interim support, or running on compensating controls with documented risk acceptance, a large share of them are applying current patch releases now, because staying on an unpatched release line while ending an entitlement to IBM support services is a combination most risk functions will not accept.

The patch releases carrying the SDK change are exactly the releases those programs are applying. Maximo 9.0.29, 9.1.21, 9.2.2, and the 9.3 September Feature Channel are not obscure branches. They are the current maintenance targets for the installed base.

There is a second-order effect that deserves attention. Many organizations are applying patches as part of a broader hardening effort, and in that context the patch is treated as a known quantity. Change boards approve a maintenance release with a familiar label. The technical review focuses on whether the patch fixes the defects the organization cares about, whether it introduces known regressions, and whether the rollback path is sound. A dependency-namespace migration hiding inside the release notes is not typically in the review scope, because it does not look like a functional change.

And the deadline week itself is the problem. September 24 is the second-to-last executable working day of this cycle. September 25 is the last. September 28 through 30 is a quarter-close short week in which teams are thin and approval paths are slow. If you discover on September 30 that a customization broke, you are discovering it during a freeze, with limited capacity to remediate and no favorable window in which to apply a corrective change.

The practical conclusion is that exposure assessment cannot wait for the patch to be applied. It has to happen now, against the code you already own, because the answer determines whether your patch window is a routine maintenance event or a remediation project.

Finding Your Exposure Before the Patch Finds It for You

The good news is that this class of exposure is highly searchable. You are looking for a namespace string, not a behavioral pattern, and grep is sufficient.

Start with the source repositories. Search every Java project that touches Maximo for the literal string com.amazonaws. That will surface imports, fully qualified class references, string literals in reflection-based code, and configuration files that name classes by name. Do not stop at .java files. Include build files, since a Maven or Gradle dependency on aws-java-sdk artifacts will be broken by the same change even if the source imports look clean. Include resource files and any XML or JSON configuration that references a client class by string.

Then search the Maximo database for automation scripts. The script source lives in Maximo's own repository tables, and a direct query against the script source column for the same string will enumerate every automation script in the system that touches AWS classes. This is the highest-value search because automation scripts are the component an administrator is least likely to have inventoried and most likely to have inherited. Run it against every environment: development, test, staging, and production, because scripts get created in production under pressure and never backported.

Then search any packaged artifacts. Unpack the WAR and EAR files, or list the JAR contents in your deployment packages, and look for the v1 artifact names directly: aws-java-sdk-s3, aws-java-sdk-core, aws-java-sdk-kms. A customization that bundles its own copy of the v1 SDK will not break when the platform JARs disappear, because it carries its own. That sounds like good news and is actually a different problem, since shipping v1 inside a customization after Amazon has ended v1 support is its own finding worth raising with whoever owns the code.

Finally, inventory your third-party solutions and ask each vendor a direct question: which version of your product is compatible with software.amazon.awssdk 2.41.34, and when does it ship. Ask for a written answer with a version number. A verbal assurance that the product "should be fine" is not a testable claim, and you will need something concrete if the patch reveals an incompatibility during a maintenance window.

Once you have the inventory, classify each finding. Code you own and can change is a remediation task with a known cost. Code a vendor owns is a dependency negotiation with an external timeline. Code that is dead but still deployed is a deletion task. The classification matters because it determines whether you can proceed with the patch on your own schedule or whether you need to sequence the patch behind a vendor release.

Remediating: Porting Code to v2 Without Breaking Everything Else

For code you own, the port is mechanical but not trivial, and the order of operations matters more than the individual edits.

Begin by pinning the new dependency explicitly in your build. Do not rely on whatever version Maximo ships at runtime. Your customization should declare a compile-time dependency on the v2 SDK artifacts at 2.41.34 so that the compiler catches every incompatible reference. Building against the wrong version and discovering mismatches at runtime converts a compile error, which is cheap, into a production failure, which is not.

Then work module by module rather than attempting a single sweeping rename. The temptation with a namespace change is a global find-and-replace from com.amazonaws to software.amazon.awssdk. That will produce a codebase that compiles in places and behaves incorrectly elsewhere, because the class names, method signatures, and object models changed along with the package. Do the port service by service: every S3 call site first, then every KMS call site, then credential and configuration plumbing.

At each call site, expect four categories of edit. Client construction moves to builder form. Configuration moves from a mutable configuration object into builder methods or system properties, and if your code relied on a globally configured client with tuned timeouts and retry policy, that configuration now needs a deliberate home, ideally a shared factory you control rather than ad hoc setup at each call site. Credential provision moves to an AwsCredentialsProvider, and if your code used BasicAWSCredentials with credentials read from a Maximo property or an encrypted store, that plumbing needs rewriting to use StaticCredentialsProvider or, preferably, a provider chain that respects the instance role when running in a managed cloud environment. Exception handling moves to v2 exception types.

Be deliberate about credentials during this port. A migration is an unusually good moment to move away from long-lived static keys embedded in Maximo configuration if that is the current pattern. The v2 provider chain makes the alternative easier, not harder, and coupling the rewrite to a credentials improvement is a justifiable use of the effort you are already spending.

Finally, regression-test the paths that the compiler cannot check. Credential resolution against the target environment, retry and timeout behavior under a degraded AWS endpoint, and the precise error messages your code logs when a call fails are all runtime behaviors. A ported v2 client that authenticates correctly and times out differently than the v1 client did has changed production behavior in a way no unit test will catch unless you specifically test for it.

Practical Implications

If you own a Maximo estate with any custom Java or automation script that touches AWS services, treat this as a live issue this week, not a documentation item.

Scope exposure immediately. Run the searches described above across source repositories, Maximo script tables in every environment, and packaged artifacts. The output is a list, and a list is manageable in a way that an unquantified risk is not.

Decide the patch posture based on what the list contains. If the list is empty, the SDK migration is a non-event for you and should not delay your patch. If the list is non-empty and entirely code you own, plan the port as part of the patch work rather than after it, so the two changes land together and get tested together. If the list contains vendor code, contact the vendors now with a specific version question and hold the patch if you do not have a supported version confirmed.

Write down the decision either way. The reason this change is dangerous is that it fails silently and late, and the only durable protection is a dated record saying that you checked, here is what you found, and here is the version of every affected component. If a customization fails in November, that record turns a forensic investigation into a five-minute lookup.

The Bottom Line

The AWS SDK for Java v1 to v2 migration in Maximo Manage is a small change with an outsized footprint. Three JARs out, a larger set of differently named JARs in, and a package namespace boundary that no import statement survives unchanged. IBM documented it accurately and completely. The gap is not the documentation. The gap is that the change ships inside patch releases that organizations are applying for an entirely different reason, during a support deadline that leaves almost no room for a remediation project discovered late.

The estates that come through this cleanly will be the ones that searched their own code before the patch rather than after. The search is cheap, the inventory is small, and the port is a known quantity once it is scoped. What is not cheap is finding out during a quarter-close freeze that a seasonal integration job has been failing silently since the maintenance window. Do the grep this week. It takes an afternoon, and it is the difference between a patch and an incident.