You’ve done the initial ERP setup. Core modules are running. Users are onboarded. Then someone from the business side sends a message: “Can we add inventory tracking? And also, can we tie it into the existing sales workflow?”
And now you’re staring at a module dependency tree, wondering what breaks if you install something new mid-cycle, whether your existing data model needs to change, and how long this is actually going to take. If you’ve been in ERP consulting or development for any length of time, this scenario is familiar. Adding modules to a running ERP isn’t hard in principle. But doing it without creating a mess for your client or your team requires more planning than most people give it.
This is the post I wish existed when I first started working on modular ERP systems.
Why Module Installation Order Actually Matters
Most documentation treats module installation as a simple checklist. Enable this, configure that, done. But order matters more than people realize, especially when modules share data models.
Think about the relationship between CRM and Sales. CRM typically owns the concept of a contact or lead. Sales builds on top of that with opportunities, quotes, and orders. If you install Sales first and later bolt on CRM, you may end up with two competing representations of a customer record. That’s a data integrity problem that’s genuinely painful to fix after the fact.
The general principle is: install foundational modules before dependent ones. That sounds obvious, but it requires you to actually map the dependency graph before you start clicking buttons. For most ERP platforms, that graph isn’t clearly documented anywhere. You figure it out by reading source code or by making mistakes.
With Fullfinity’s modular architecture, modules declare their dependencies explicitly, which means the system can resolve the installation order for you. But even so, you still need to think about the business logic dependencies, not just the technical ones. The system won’t tell you that your warehouse team configured custom approval flows in Inventory that will need to be updated when you add the Purchasing module on top.
Evaluate the Data Model Impact Before You Install Anything
This is the step most people skip. Before installing a new module, you should understand what it does to your existing schema.
Traditional ERP platforms make this painful because schema changes require migration files, DBA sign-off, and scheduled downtime. So people avoid installing new modules mid-project because the migration risk is too high. That fear is actually reasonable given the tooling.
Fullfinity handles this differently. Because schema changes are managed automatically through the ORM rather than through hand-written migration files, adding a new module that extends an existing model doesn’t require you to manually author a migration or coordinate a maintenance window. The schema adapts. If you want to understand why that matters at scale, the post on Zero Migration Files: How Fullfinity Handles Schema Changes Automatically covers the mechanics in detail.
But even with automatic schema management, you should still audit what a new module adds:
- Does it introduce new tables or extend existing ones?
- Does it add required fields to models that already have data?
- Does it change any existing relationships (foreign keys, many-to-many links)?
- Does it alter default behaviors through hooks or overrides?
You don’t need to be paranoid about this. You just need to be informed. Run module installation in a staging environment first and inspect what changed. That’s not optional. That’s just basic practice.
Access Control and Permissions Don’t Configure Themselves
This is the one that bites consultants most often. A new module gets installed, and two weeks later someone from the client’s finance team is asking why their junior staff can see customer credit limits in the new accounting view.
Every new module you install brings its own permission model. And that permission model doesn’t automatically inherit the access restrictions you’ve already configured for your existing roles.
When installing a new module, you need to explicitly review:
- What new roles or permission groups the module creates
- Whether existing roles need to be updated to include or exclude new resources
- Whether any default permissions are too permissive for your organization’s security posture
On Fullfinity, the access-aware ORM means that query results are already filtered based on the current user’s access context. So a user who shouldn’t see certain records won’t see them, even if a developer forgets to add a manual filter. That’s a good safety net. But it doesn’t replace intentional permission configuration. The ORM enforces what you’ve defined. You still have to define it correctly.
Set aside dedicated time for access control review after every module installation. It’s not glamorous work but skipping it creates the kind of security problems that end consulting relationships.
Integration Points: Where New Modules Connect to Existing Workflows
Modules don’t exist in isolation. They connect. And connection points are where bugs live.
When you add a new module to an existing ERP installation, you need to identify every place that module touches an existing workflow. Some of these connections are automatic and well-defined. Others are soft integrations that depend on field mappings, event hooks, or manual data entry steps that users have developed their own habits around.
A concrete example: you’re adding the eCommerce module to a system that’s been running Sales and Inventory for six months. Your client’s sales team has been manually creating orders based on phone calls and emails. Now orders are going to start flowing in from the online store. Same order model, different origin. But the approval workflow your client built assumes a human reviewed every order before it was confirmed. That assumption just broke.
This isn’t a technology problem. It’s a process problem that shows up as a technology symptom. Before installing any module that introduces a new data source or workflow origin, sit down with the actual users and map out what changes. Don’t just ask “does this affect your work?” Ask “walk me through how you create an order today.” The difference in what you learn is significant.
Testing in Staging Is Not Negotiable
You’d think this goes without saying. It doesn’t. People install modules directly in production environments all the time, especially when they’re under deadline pressure or when a client is breathing down their neck.
Here’s a practical staging checklist for module installation:
- Restore a recent production data snapshot to staging
- Install the new module and run through dependency resolution
- Run the module’s built-in test coverage if it has any
- Manually test every integration point you identified in your workflow audit
- Have a real user (not just a developer) test the new module’s UI flows
- Check query performance on the tables the new module touches most
- Verify that existing reports and dashboards still return correct data
- Document any configuration changes you made during testing so you can replicate them in production
That last point is underrated. The “it worked in staging” problem often happens because someone made a config change during debugging and forgot to write it down. When they go to production, the config is different, and the behavior is different.
If your ERP runs on async architecture, pay particular attention to testing workflows that involve background jobs or event-driven processes. A module that triggers async tasks can interact with existing async jobs in unexpected ways. The post on Async Python in ERP: Why Blocking I/O Is Killing Your Throughput gets into why async ERP architecture behaves differently from synchronous systems, and understanding that helps you write better test cases for module interactions.
Extending Modules Without Breaking Existing Behavior
At some point you’ll need to customize a module, not just install it out of the box. Maybe your client needs a non-standard field on the inventory model. Maybe they want the sales order confirmation email to include data from a custom module you built. Whatever it is, you need to extend the default behavior.
This is where a lot of ERP platforms fall apart. The common pattern is monkey-patching, which is basically reaching into a class or function at runtime and overriding its behavior with your own code. It works until it doesn’t. And it especially doesn’t work when the underlying module gets updated and the internals change, leaving your patch silently broken or throwing cryptic errors.
The better approach is inheritance-based extension. You extend the base model or class, override what you need to change, and leave everything else intact. Fullfinity is designed to support this properly. You don’t need to touch the core module’s code. You create an extension in your own module, declare the inheritance, and override specific methods or fields. When the base module updates, your extension still works because it’s extending a stable interface, not patching internals.
For a more detailed look at why this matters and how it works in practice, the post on ERP Customization Without Monkey-Patching: A Better Way to Extend Your System is worth reading before you start writing any extension code.
The practical rule for module extension work is: never modify the source files of a module you didn’t write. Everything should be done through declared extension points. If you find yourself editing a vendor module’s source code to make something work, that’s a sign the extension architecture isn’t doing its job, and you should find a different approach.
Rollback Planning: Because Things Go Wrong
Even with perfect preparation, sometimes a module installation causes problems you didn’t anticipate. Having a rollback plan isn’t pessimistic. It’s just professional.
Before any production module installation, you should know the answers to these questions:
- Can the module be uninstalled cleanly, and what happens to the data it created?
- Is there a database snapshot from immediately before installation?
- Who needs to be notified if you need to roll back?
- How long will a rollback take, and what’s the acceptable downtime window?
Some modules can be uninstalled cleanly. Others create schema changes that are difficult to reverse. Know which category you’re dealing with before you start.
For modules that create significant schema changes, your pre-installation snapshot is your only real safety net. Automated schema management is great for forward migrations, but going backward is always more complicated than going forward. Treat your pre-installation snapshot as something you’d actually use, not just a box you’re checking.
Working With Clients Through Module Rollouts
This section is specifically for consultants. Your client doesn’t care about module dependency graphs or ORM internals. They care about whether their team can do their jobs.
The framing that works best for client communication around module installation is: impact, timing, and training.
Impact: what changes for the users? Not what the technology does, but what their day looks like differently.
Timing: when will the change happen, what’s the downtime window if any, and when should they expect things to feel normal again?
Training: who needs to learn new things, and how will they learn them?
You don’t have to walk a client through every technical decision you make. But you do have to manage their expectations honestly. If there’s a risk of disruption, say so. Clients who get surprised by disruption lose trust. Clients who were warned about a disruption that was then handled professionally actually come away with more confidence in you.
On large multi-module rollouts, consider a phased approach. Install one or two modules, stabilize, train users, and then move to the next phase. It’s slower but it reduces the surface area of problems you might encounter at any one time. And it gives your client’s team time to build confidence with new features before you add more complexity on top.
Conclusion
Installing ERP modules is one of those things that looks simple until you’ve been bitten by a dependency conflict, a broken permission model, or a workflow assumption that silently stopped being true. The developers and consultants who handle this well aren’t smarter. They’re just more systematic.
The key takeaways:
- Map dependencies before you install, not after. Both technical dependencies and business logic dependencies. They’re not the same thing.
- Staging isn’t optional. A real data snapshot in a real staging environment is the only way to catch the problems that happen when a new module meets existing data.
- Extend through inheritance, not patching. If your customization strategy involves editing vendor module files, you’re building future problems for yourself.
If you’re evaluating Fullfinity for a client project or your own business, the modular architecture is genuinely one of the better-thought-out parts of the platform. Explore the full Fullfinity ERP platform to see how the module ecosystem fits together, and browse the rest of the blog if you want to go further into the technical specifics.
