AS-IS and TO-BE: The Map Every Application Modernization Needs
Barona's Consulting Department explains how AS-IS/TO-BE analysis helps you understand the current state of your applications and design the right transformation.
Every time a company calls us to "modernize its applications," the first question we ask is always the same: do you know exactly what you have today?
In most cases, the answer is an awkward silence followed by "more or less." And that "more or less" is exactly the problem AS-IS and TO-BE analysis is designed to solve.
What do AS-IS and TO-BE mean?
They are two snapshots of the same system taken at different points in time:
-
AS-IS (how it is): An accurate, objective description of the current state — how processes work today, which applications support them, what integrations exist, what data flows between systems, and where the bottlenecks are.
-
TO-BE (how it should be): The design of the desired future state — how processes should work after the transformation, which technologies will enable them, and what new capabilities the organization will have.
The gap between AS-IS and TO-BE is the transformation project.
Why AS-IS is harder than it looks
In theory, documenting the current state sounds simple. In practice, it is the most complex and most valuable work in the entire process.
Organizations accumulate years of technical decisions, workarounds, informal integrations, and tacit knowledge that lives in the heads of two or three key people. When those people are unavailable — or worse, no longer with the company — the knowledge disappears.
In real projects, we have found:
- Applications no one knows the purpose of but no one dares to turn off because "something might break."
- Point-to-point integrations between systems that are not documented anywhere — they only work because someone configured them eight years ago.
- Duplicate databases holding the same information in three different systems, with none of them being the source of truth.
- Manual processes that compensate for application limitations and have become so routine that no one questions them.
The AS-IS assessment methodology
A rigorous AS-IS assessment has four components:
1. Application inventory
The first step is to know exactly which applications exist. This includes:
- Business applications (ERP, CRM, proprietary systems)
- Infrastructure applications (Active Directory, Exchange, file servers)
- Departmental applications (critical spreadsheets, Access databases, in-house applications)
- Cloud applications (SaaS) and their integrations with on-premises systems
For each application, we document: version, vendor, implementation date, active users, business criticality, and vendor support status.
2. Business process mapping
Applications do not exist in a vacuum — they support processes. For each critical process, we document:
- Who runs it and how often
- Which applications are involved and in what order
- What data goes in and what data comes out
- Where there are manual steps that could be automated
- Where there is rework or duplicate validation
This phase requires interviews with the actual users of the process, not just the IT team. Business users know about workarounds that IT does not know exist.
3. Integration analysis
The integration map is often the most surprising part of the AS-IS. We document:
- Which systems communicate with each other
- How they communicate (API, flat files, shared database, manual integration)
- How often, and what data they exchange
- What happens when an integration fails
A well-built integration diagram reveals hidden dependencies that can become critical risks during the migration.
4. Identifying pain points
The AS-IS is not only descriptive — it is also diagnostic. For each process and application, we identify:
- Unacceptable response times
- Frequent errors and their root causes
- Functional limitations that force workarounds
- Security or compliance risks
- Hidden costs (licensing, maintenance, administration time)
Designing the TO-BE: the art of the possible
With the AS-IS documented, the TO-BE design can be rigorous instead of speculative.
The TO-BE is not simply "the same thing, but in the cloud." It is an opportunity to rethink processes from the ground up, taking advantage of the capabilities that modern technologies enable.
Principles that guide TO-BE design
Eliminate before you migrate: If a process has unnecessary steps, remove them before automating it. Automating an inefficient process only makes it inefficient faster.
Consolidate before you integrate: If three systems hold the same information, the TO-BE should have a single source of truth, not three integrated systems.
Standard before custom: Modern platforms such as Microsoft 365 and Azure have standard features that cover 80% of use cases. Customization should be the exception, not the rule.
Data first: The design of the TO-BE data model matters more than the choice of technology. A good data architecture can survive multiple technology changes.
The TO-BE in layers
We design the TO-BE in three layers:
- Process layer: How business processes should flow in the future state.
- Application layer: Which applications will support those processes and how they will integrate.
- Infrastructure layer: Which platform those applications will run on (Azure, M365, on-premises, hybrid).
The gap: the transformation plan
The difference between AS-IS and TO-BE defines the transformation work. But not everything can be done at once.
We prioritize the transformation based on three criteria:
- Business impact: Which change creates the most value for the organization?
- Technical complexity: How difficult is the change to implement?
- Operational risk: How critical is the system being modified?
The result is a transformation roadmap with initiatives ordered by priority, clear dependencies, and measurable success criteria for each phase.
A real example: from silos to an integrated platform
In a recent project for a distribution company, the AS-IS revealed:
- A 12-year-old on-premises ERP with no vendor support
- A CRM in an Excel file shared by 15 salespeople (with a different version on each computer)
- E-invoicing integrated manually — someone copied data from the ERP into the invoicing system every day
- Management reports that took 3 days to prepare
The TO-BE design included:
- Migrating the ERP to the same vendor's cloud version
- Implementing Dynamics 365 Sales as a unified CRM
- Automatic ERP-to-invoicing integration via API
- Power BI connected directly to the ERP for real-time reporting
The result: reports available in minutes, zero manual integration work, and a single source of truth for all commercial information.
Conclusion
AS-IS/TO-BE analysis is not a bureaucratic exercise — it is the difference between a successful transformation and a project that ends halfway, with new systems that replicate the problems of the old ones.
Investing time in deeply understanding the current state before designing the future is what allows transformations to succeed. At Barona Enterprise, this analysis is always the first step of every modernization project, without exception.
