
An org can keep running while becoming harder to change. The question is whether the decisions that shaped it still serves the business you are today. A productive conversation starts with understanding what is there, why it exists, and what your team needs next.
1. Can you explain each customization?
Start with a small inventory of the workflows that matter most. For each customization, record the business requirement, the people who use it, and the person who can explain its purpose. Include the spreadsheets and manual steps that sit around the system.
Treat an unanswered question as something to investigate. A feature that looks redundant may support an important exception. Equally, a workaround that once solved a real problem may have outlived the process it was built for.
2. What is making upgrades difficult?
Replace a general concern about upgrading with a specific list of dependencies. Which custom processes need validation? Which integrations depend on a particular behavior? Where is the team relying on knowledge that has never been documented?
This creates a practical agenda for assessment and testing. It also makes it easier to distinguish work that is necessary from improvements that can happen in a later phase.
3. Could standard functionality meet the need?
Review the requirement before debating the solution. Describe what the business must accomplish, then compare the current implementation with the standard functionality available in the relevant product and release.
The goal is a deliberate decision about each customization. Keep what earns its place. Where a simpler option meets the need, consider the effects on reporting, integrations, training, and the people who own the process.
4. Where could the team see an early improvement?
Choose a bounded workflow with an engaged owner and a result the team can recognize. That might mean removing a repeated reconciliation step or making a common exception easier to resolve. Agree how you will assess the result before changing the system.
Use the first phase to test the approach as well as the technology. Document what you learn and let those findings shape the sequence of the larger roadmap.
5. What access does the assessment need?
Define the questions and the necessary access together. A read-only configuration review has a different scope from a process assessment that examines records, integrations, and user behavior. The assessment should make that distinction clear.
A useful starting point is a shared list of priority workflows, known constraints, and decisions to be made.
Turn the questions into a practical next step.
Explore Fresh Start

