Tenant configuration review before an enterprise renewal

Why old tenant settings cause renewal trouble

Old tenant settings usually begin as sensible fixes. A team turns on a flag for one account, adds a custom rule for a special workflow, or writes down a manual step so billing or reporting goes out on time. Then the business changes, the project ends, or the team moves on, but the setting stays.

That is where renewal trouble starts. People often remember that a setting exists, but they do not remember why it exists. The reason may sit in an old ticket, a chat thread, or one person's memory. By renewal time, those leftovers can look like part of the standard setup simply because nothing has broken yet.

A good review usually shows how much of the tenant still depends on old decisions. One exception points to a role nobody uses anymore. A feature flag still protects a launch from last year. A manual spreadsheet export still happens every Friday because someone once said finance needed it, and nobody checked again.

Staff changes make this worse. The person who added the exception leaves. The next admin inherits a pile of rules with no clear owner. Most teams leave everything in place because removal feels risky. That is how short-term fixes turn into permanent baggage.

Manual workarounds spread quietly. One step lives in a shared document, another in a Slack message, another in a note pasted into the ticket system. After a while, nobody sees the full process. The tenant works only because several people remember extra steps that the system should not need.

Renewals can lock that mess in for another term. Once the contract renews, old complexity starts to look like a real requirement. Support teams keep carrying it. New admins learn it as normal. Costs stay higher than they should, and simple changes take longer because every change has to avoid years of exceptions.

If you clean this up before renewal, you renew the service you actually need, not the one built around forgotten workarounds.

What drift looks like in a live tenant

Drift rarely looks dramatic. It usually shows up as small settings that made sense once and then stayed in place for years. During a review, teams often find choices nobody would approve today, yet everyone has learned to live with them.

One common sign is a feature flag with no owner. A team turned something on for a pilot, another team inherited it, and now nobody knows whether the flag protects a real workflow or an old test. People worry about breaking something, so the flag stays.

Custom rules create the same kind of mess. Someone asked for a special case, a manager approved it, and the rule never went away. The original request is gone, but the rule still changes who gets notified, which records need extra checks, or how an order moves through the system.

Manual workarounds are even easier to miss because staff treat them as normal work. A coordinator exports a CSV every Friday, fixes a few fields, uploads it somewhere else, and sends a note to finance. If you ask why, the answer is often "because that is how we do it." That usually means the software and the real process split a long time ago.

Permissions drift in quieter ways. People change jobs, teams merge, contractors leave, and access keeps spreading. Months later, someone in sales operations can still edit settings that belong to support, or a former manager's group still has admin rights that nobody reviewed.

Approval chains also grow by accident. A request gets approved in one system, then approved again inside the tenant, then confirmed in chat. No one designed that loop. It appeared one patch at a time, usually after a complaint or a rushed fix.

You can usually feel drift before you can map it. Staff can name steps they dislike but cannot explain. Settings exist for customers or teams that no longer exist. Reports need hand edits before anyone trusts them. Access levels still reflect last year's org chart.

This costs more than admin time. It hides risk, slows teams down, and makes renewal talks harder because the next contract can preserve years of exceptions and extra work that should have been removed already.

Who should join the review

A review fails when only one team shows up. Old flags, custom rules, and manual workarounds stay in place because each person sees only one slice of the tenant.

Keep the room small but complete. Five people is usually enough, as long as each one can answer real questions and approve changes.

The tenant admin should be there because they know what is turned on, what changed over time, and which settings nobody wants to touch. The operations or support lead should join because they feel the daily pain. They know which odd rule creates tickets every week and which workaround staff repeat by hand.

Finance also needs a seat. Drift costs money, and finance can spot paid features nobody uses, duplicate environments, and contract terms that no longer match reality. Security or compliance should join as well, because some settings exist for a reason. That person can say which controls still matter and which ones became dead weight after earlier audits or policy changes.

You also need a business lead who can approve removal. Without that person, the group will find problems and still keep every bad setting "just in case."

A simple example makes this clear. Support may complain about a custom approval rule that slows every order. The admin can show where it lives. Security can confirm it is no longer required. Finance can show the extra admin cost. The business lead can then remove it instead of delaying the decision for another quarter.

Keep observers out unless they own a decision. Large meetings turn into status updates, and nobody wants to delete anything. If two teams disagree, ask them to bring evidence: ticket volume, audit needs, spend, or user complaints.

If you do not have all these roles in-house, one person can cover two seats. In smaller companies, a founder, head of operations, and an outside CTO advisor can often cover the full review and still move fast.

How to run the review step by step

Start with a full export of the tenant. Pull every setting, feature flag, routing rule, approval path, exception, and admin override into one sheet. If the product does not support a clean export, build the list from admin screens and audit logs. A review falls apart when people look only at the settings they already remember.

Once you have the list, give every item two plain labels: owner and purpose. Use a person or team name for the owner, not "admin" or "operations." For purpose, write one short sentence that explains why the setting exists, such as "blocks orders above $25,000 until finance approval." If nobody can name an owner or explain the purpose, that item already needs attention.

Then check whether each item still gets used. Guessing is how old drift survives. Look for proof in system logs, support tickets, recent transactions, report output, or change history. "We think sales still needs it" is not proof. "This rule fired 14 times in the last 60 days" is proof.

A simple sort works well:

• Keep: still used, still correct, clear owner
• Change: still used, but the logic or threshold is wrong
• Remove: no recent use, no clear reason, or replaced by another feature
• Test: unclear impact, risky dependency, or missing evidence

Write the decision next to each item while the review is happening. If you leave blanks for later, people forget the context and the meeting becomes another meeting.

Timing matters more than most teams expect. Finish these decisions before vendor pricing talks begin. Once procurement starts, teams get cautious and stop removing anything because they fear breaking the renewal. That is how five years of drift gets copied into another contract term.

A small example makes this real. Say you find a custom approval rule added during a 2021 rollout. Nobody owns it now, but logs show it has not fired in nine months because a newer workflow replaced it. Mark it for removal, note the evidence, and confirm the fallback path in testing. One cleanup like that can save admin time every week and keep a dead rule out of the next agreement.

How to judge flags, rules, and workarounds

The review gets easier when every item has to earn its place. Treat each feature flag, custom rule, and staff workaround like a line item on a budget. If nobody can explain why it still exists, move it toward removal until someone proves otherwise.

Start with the current problem, not the old story. A flag that once protected a rollout may solve nothing now. A custom billing rule may have helped one account manager two years ago, then quietly spread to ten customers who never asked for it.

Use the same checks every time:

• Name the problem it solves today in one sentence.
• Count who uses it and how often.
• Estimate the ongoing cost in support time, testing, training, and upgrade risk.
• Decide whether it should stay, merge with another rule, or go away.

Frequency tells you a lot. If a workaround runs every day, you may have a product gap worth fixing. If someone uses it once a quarter and only one person remembers how, that is usually drift, not a business need.

Look hard at duplicates. Teams often create two rules with different names that do the same job, such as special approval paths for the same customer type. Merge them before renewal. Fewer rules mean fewer surprises when the vendor changes pricing, permissions, or default behavior.

Manual workarounds deserve extra skepticism. A spreadsheet export, a copy-paste step, or a side Slack message may look cheap, but the hidden cost adds up fast. One person spends 15 minutes a day, support answers confused users, QA tests both the normal path and the workaround, and nobody trusts the numbers.

Write one plain note for every decision. Keep it short: what the item does, why you kept or removed it, who approved the call, and when you will review it again. Good notes stop the same argument from coming back at the next renewal.

A simple renewal review example

A mid-sized company is six weeks away from renewing its service desk platform. The contract looks routine, so procurement starts with pricing. Then the support lead points out a problem: the tenant carries years of small changes, and nobody knows which ones still help.

The team runs a review before the renewal meeting. They bring in one support manager, one operations lead, one admin, and one person from finance. That mix matters because each group sees a different kind of waste. Support feels the daily friction. Admins know what changed. Finance sees what the company still pays for.

They find a tenant full of leftovers. Dozens of old feature flags stay on even though teams stopped using the related workflows. Several custom routing rules were built for past org charts. Three manual reports still land in managers' inboxes every morning because nobody trusts the built-in dashboard.

One rule causes the biggest delay. Urgent cases from a large customer still go to a queue that belonged to a specialist team two years ago. That team merged into general support, but the rule stayed. Tickets now sit for 40 minutes before someone reassigns them by hand. People adapted to the delay, so the issue started to look normal.

The review team checks each item with a plain test:

• Does this setting support a current process?
• Who asked for it, and do they still need it?
• What breaks if we turn it off?
• Are people doing manual work because the setup is wrong?
• Does this affect cost, response time, or reporting?

By the end of the week, they remove unused flags, retire old routes, and replace two manual reports with a cleaner dashboard. They keep one custom rule because it still matches a contract promise. They also fix the urgent-case route before renewal talks begin.

That changes the contract discussion. Procurement no longer renews a messy setup just because it already exists. They renew a cleaner tenant, with fewer exceptions to defend and less daily handwork for the support team.

Mistakes that keep bad settings in place

Most bad settings survive because teams review only what the admin panel shows. That catches obvious flags and visible rules, but it misses the things people built around the tenant over time. Support notes, API scripts, SSO exceptions, import jobs, and hidden defaults often shape daily work more than any checkbox on screen.

Testing is the next place teams give up too early. Old rules stay in place because no one wants to spend two days proving they are safe to remove. That feels cheaper in the moment, but it locks last year's workaround into next year's contract. A rule made for one noisy customer, one migration, or one reorg can keep causing odd approvals and failed handoffs long after the original reason is gone.

Another weak point appears when the vendor sets the scope. Vendors usually review what affects licensing, support load, or renewal pricing. They often do not dig into tenant-specific exceptions, one-off rule chains, or feature flags your team turned on during a crisis. Your team needs its own list and its own questions.

The mess rarely lives in the product alone. It also lives in spreadsheets, macros, copied CSV files, shared inbox steps, and side processes that nobody wrote down. If finance fixes billing data in Excel every month before upload, that is part of the tenant setup in practice. If operations runs a manual export every Friday, that is a workaround worth naming and testing.

Ask the same four questions for every exception:

• Who asked for it, and do they still need it?
• What breaks if you turn it off?
• Who does manual cleanup because of it today?
• Can you test removal before renewal terms are locked?

Timing matters here too. If legal already started the renewal draft, people stop asking hard questions. They want the deal done, not another round of discovery. Run the review before pricing, contract drafts, and approvals start, or the agreement will preserve years of drift with fresh signatures.

Quick checks before you sign

A renewal can lock in years of extra cost and hidden friction. A short review right before signature often catches settings that nobody would approve if they saw them clearly today.

Use this pass with the people who work in the tenant every week.

Give every custom rule one named owner. If nobody wants to own a rule, ask why it still exists. That owner should explain what it does, who asked for it, and what fails if you remove it.

Check each paid add-on against recent usage, not old assumptions. If a team has not used it in the last quarter, move it into a remove-or-justify bucket.

Put an end date on every manual workaround. "Temporary" fixes often stay for years because no one sets a stop date and no one gets the cleanup task.

Test risky removals during a safe window. Do not switch off flags or delete rules during payroll, month-end close, or a big release. Give teams time to watch for side effects.

Make finance and operations agree on the same scope before anyone signs. One team watches cost. The other watches day-to-day risk. Both need the same list.

A small example makes this concrete. A company may still pay for an approval add-on bought during a compliance project two years ago, keep a custom routing rule for a manager who left, and rely on a spreadsheet export because one report never got fixed. None of those items looks dramatic on its own. Together, they raise the bill and keep extra work alive.

One simple rule helps: do not renew any setting by default if it has no owner, no recent usage, or no test plan. That takes some discipline, but it is cheaper than carrying drift for another year.

What to do next

After the review, move fast. The work loses value when decisions sit in chat, meeting notes, or someone's memory. Give every change an owner, a due date, and a short reason.

A simple follow-up plan works better than a long cleanup project nobody finishes. Remove old flags, duplicate rules, and manual steps that add work but do not protect revenue, compliance, or a live customer need. Keep settings that still support an active promise, contract term, or internal policy, and write down the reason. Test anything that has unclear usage or a risky dependency before removing it. For edge cases, set a real review date instead of leaving them in a "someday" bucket.

Push low-value items out before the new term begins. If you renew first and clean up later, those leftovers usually stay for another year. Teams rarely revisit old exceptions once the contract is signed and the pressure is gone.

Write down the final decisions in plain language. Skip internal shorthand. The record should answer four questions: what changed, why it changed, who approved it, and when the team should check it again. The next admin, operations lead, or finance partner should be able to understand it in two minutes.

If your team is buried in delivery work, outside help can speed this up. A fresh reviewer often spots drift faster because they did not live through every temporary fix. That matters most when manual workarounds have become normal and nobody remembers the original reason.

For teams that need that kind of support, Oleg Sotnikov at oleg.is can help review stale settings, cut manual work, and turn the findings into a cleaner renewal plan. His Fractional CTO work is usually practical: sort the mess, make the calls that matter, and leave behind a tenant the team can actually manage.

The best outcome is boring in a good way: fewer exceptions, fewer hidden steps, and a short list of settings you can still explain on renewal day.