Reading a factory before you quote it.

1Service Center first

Before Service Studio, before the architecture diagram someone sends over, before the roadmap deck. Service Center tells you the truth about what has actually been built, not what was intended.

• The first pass is counting. How many applications, how many modules, and how those numbers relate. A hundred modules across six applications is a different animal from a hundred modules across forty. Are they using solutions at all, or is deployment a manual assembly job every time.
• Then Forge. Which components are in there, and the question that matters more than the list itself: were they cloned before they were changed. A modified Forge component that was never cloned is an upgrade that can never happen, and nobody finds out until the day it has to.
• Then naming. Not because naming is important in itself, but because naming is the cheapest available evidence of whether the factory had a standard and whether anyone held to it. Consistent naming across a hundred modules means there was a discipline. Three naming schemes in the same application means there were three eras, probably three teams, and the handovers between them were not clean.
• Then the logs. Exceptions, timeouts, slow code warnings. Not to fix them. To see what the platform has been complaining about while everyone got used to ignoring it.

2Then the dependency picture

Discovery and AI Mentor Studio, looking for what points at what.

• Circular references mean the module boundaries are decorative.
• Upward references, where a foundation module reaches back into something above it, mean the layering was breached at some point and never repaired, so anything you touch at the bottom now moves things at the top.
• Which modules contain the entities. This one is easy to skip and expensive to skip. A module with entities in it cannot simply be moved. Moving it is a data migration, with a downtime window and a rollback plan, and it will not fit in the estimate you gave for the refactor you thought you were doing.

None of this is sophisticated. It is counting, reading names, and looking at what points at what. The unglamorous checks are the ones that actually move the number, and they are the ones most often skipped because they feel too basic to bother with.

3The four things that blow up an estimate

Everything above feeds four questions. In our experience these are where the surprises come from, in roughly this order of damage.

• Where the entities actually live. Covered above. It is the difference between a refactor and a migration.
• Extensions, and anything with C# in it. This is the part that does not travel. If you are looking at O11 to ODC, the extension inventory sets the timeline more than the module count does, and no amount of good intent about the application layer changes that.
• Integrations you do not control. Not the ones on the architecture diagram. The quiet ones, the endpoint someone stood up in 2019 that nobody has touched since and that has no owner left in the building. Those are the ones that bite, because you cannot test against a system nobody can give you access to.
• How much logic sits in the UI layer. Business rules in screen actions instead of behind a service are invisible to every scan you just ran. They surface when you try to reuse anything, and they turn a two week job into a six week one.

4Then stop reading and talk to the team

At some point the read stops paying. The code tells you what was decided. It cannot tell you why, and only the people who were there can.

This matters more than it sounds, because roughly half of what looks wrong in a mature factory is a reasonable answer to a constraint nobody wrote down. A licensing limit. A go-live date that could not move. An integration that only accepted one shape of payload.

Walk in and call that a mistake and you have told the team you did not do your homework, and you have also quoted for undoing something that should stay.