Siebel upgrade checklist

A Siebel upgrade moves a binary, a repository, and every behavior the business already depends on. Workflows, inbound services, Open UI customizations, and the jobs that leave the database overnight all travel with it. This is the sequence to finish before a date goes on a calendar.

Name one Monday path

Before tools, name one business path that has to work when people come back. A case a service rep can update. An order that prices and submits. A batch that finance already trusts. Write it the way the person who does the job would describe it, including the status values they actually use.

That path is how you find scope. Follow the fields it writes. Then the workflow, runtime event, or business service that stamps them. Then the EIM job or the EAI / web service that leaves Siebel. Two of those layers often disagree about what a status means. An upgrade will not reconcile them. It will surface them at the worst hour.

If you cannot name the path, you do not have an upgrade plan. You have a window on a calendar.

Know which kind of upgrade this is

The work changes with the starting point. Do not collapse these into one weekend.

• A thick-client or high-interactivity UI moving onto Open UI — the IP2014 generation is the usual example — is an interface project as much as a repository project. Buttons, menus, and applets do not land where the old screenshots say they will. Budget time to look at the manifest, not only at the merge report.
• A later hop, such as 16 to 20 to 22 to 23 along a real patch line, is workspace, Web Tools, and runtime-repository work. Open UI is already there, and it is often already customized. The risk is a local change that never made it into the workspace you plan to upgrade.
• A CSPU or monthly patch set is its own pass. Read the pre-release notes for the workflows and business services you call. Count the patches that touch your repository, which is a shorter list than the full bulletin.

Checklist before the date is real

1. Repository access. Someone can open it, in Siebel Tools or Web Tools, and export what you will diff. A shared login nobody wants to use is the first task.
2. Workspaces and versions. Name the integration workspace you will upgrade. Separate what is checked in, what exists only in a local database, and what was changed in the runtime and never written down.
3. Workflows and eScript on the Monday path. List the workflows and the business services they call. Mark which are stock with a property change and which are copies nobody has opened in years.
4. Open UI. Presentation model and physical renderer overrides, manifest files, and third-party controls. If a button disappeared once already, the manifest and the method menu are both in scope.
5. EIM. Interface tables, columns, and the jobs that run after hours. An upgrade that succeeds in the UI and fails the nightly load is not done.
6. EAI and web services. Inbound and outbound. The WSDLs the other system still generates against. Any external content pulled into an applet. External business components, if the data is supposed to stay where it is.
7. Pricing, eligibility, and asset-based ordering. If orders are on the Monday path, say so. Configurator and pricing procedures are where “it worked in the test database” goes to fail.
8. Data quality and sync. EDQ or Loqate jobs, Siebel Server Sync for Microsoft 365, and any other job that writes the same fields a user edits. Those jobs do not pause because the UI was upgraded.
9. Environments. Dev, test, and production, including where they are hosted. An AWS-hosted Siebel stack still needs a rollback a person can execute.
10. Named people. A Siebel admin, a DBA who can take the backup you named, and someone from the business who will sit with the Monday path. Those three belong on the checklist beside the statement of work.

What to test

Test the Monday path in the target UI, in the browser users actually have, against data that has production’s shape. A five-row sample that never hits your branching will pass and teach you nothing. Then test the job that runs when nobody is watching.

Skip the fantasy regression suite of several hundred steps nobody will run. Keep a written list of the transactions that would page someone. Ten is enough if they are the right ten.

Run rollback once, on a non-production copy, before the weekend you might need it. If rollback means “restore the database and hope the repository matches,” write down who restores it and how long that took the last time anyone tried. A rollback you have not timed is a hope.

After cutover

Hypercare is a queue. The map stays with the admin who will still be there next quarter: which workspace was promoted, which manifest changed, which EIM job was re-pointed, and which defect is a pre-existing disagreement between a workflow and a screen.

Treat the unexplained pile as the project. Configuration the current admin can open, customization someone can still find, and behavior nobody can explain are three different kinds of work. The third kind is why upgrades slip. Calling it a ticket does not make it smaller.

Siebel CRM consulting at this practice is that project: one path, a written scope, and a handoff. A weekend and a rollback still need that named Monday path.

If the environment cannot be rebuilt except by hand, the upgrade also includes the release path: Ansible, Terraform, and a GitHub Actions or GitLab CI pipeline. That is build automation, scoped to this system.

Patch notes and upgrade write-ups from the field are linked on the resources index. They live on Bloomspire. This page does not republish them.