DEV Community: Zara Siddiqui

🚀 5 Hidden Challenges Developers Face When Migrating to Dynamics 365 (And How to Fix Them)

Zara Siddiqui — Tue, 24 Mar 2026 12:43:11 +0000

🟢 Intro

The first time I worked on a Dynamics 365 migration, I thought it would mostly be about moving data and rewriting a few customizations.

That didn’t last long.

Things started breaking in places I didn’t expect — integrations failed without throwing proper errors, data didn’t line up, and some features just stopped behaving the way they used to. What looked simple on paper turned into days of debugging.

In one of the projects I worked on at Dynamic Netsoft (https://dnetsoft.com/), we ran into multiple issues that weren’t even obvious during planning. Most of them weren’t “complex” problems — just things you don’t notice until you’re deep into the migration.

Here are a few that stood out.

🟡 Quick Context

This is based on migration work involving legacy systems (like Dynamics AX and other ERPs) moving into Dynamics 365.

This isn’t from a project manager’s view — this is from the developer side, where things actually break.

⚠️ Challenge #1: Data Migration Isn’t Just “Data Transfer”
What actually happens

You move the data, run the import, and everything looks fine.

Then you start using the system.

Missing relationships
Duplicate entries
Broken references
Why it happens

Legacy systems usually have inconsistent data. Over time, small issues pile up — and migration exposes all of them at once.

How it affects developers

You end up debugging what looks like a code issue, but it’s actually bad data.

How to fix it
Clean data before migration
Use a staging database
Validate relationships, not just fields
Run multiple test migrations
Example

if (sourceRecord.CustomerId == null)
{
    throw new Exception("Missing Customer ID - migration halted");
}

if (!targetDb.Customers.Exists(sourceRecord.CustomerId))
{
    Log.Warning("Customer reference missing in target system");
}

Simple Flow
Legacy System → Data Cleanup → Staging → Validation → Dynamics 365

We once spent two days chasing a bug that turned out to be a missing relationship in the source data.

⚠️ Challenge #2: Customizations Don’t Translate Cleanly
What actually happens

You try to replicate old custom features… and they don’t behave the same way.

Why it happens

Dynamics 365 doesn’t support the same customization approach as older systems. It’s extension-based, not direct modification.

How it affects developers

You can’t just move code — you have to rethink it.

How to fix it
Don’t blindly copy old logic
Redesign using D365 best practices
Use extensions properly
Example

[ExtensionOf(classStr(SalesTable))]
final class SalesTable_Extension
{
    public void validateWrite()
    {
        next validateWrite();

        if (this.CustomField == "")
        {
            throw error("Custom field cannot be empty");
        }
    }
}

Concept Shift
Old System → Direct Code Changes D365 → Extension-Based Approach

In one project, rebuilding a feature from scratch was faster than trying to “migrate” it.

⚠️ Challenge #3: Integration Breaks in Unexpected Ways
What actually happens

APIs and integrations that worked before suddenly stop working properly.

Sometimes they don’t fail loudly — they just stop syncing data.

Why it happens
API structure changes
Authentication differences
Data format mismatch
How it affects developers

Silent failures = harder debugging.

How to fix it
Add proper logging
Test integrations early
Validate payloads
Example

app.post("/sync-data", async (req, res) => {
    try {
        console.log("Incoming Payload:", req.body);

        const response = await axios.post(D365_API, req.body);

        console.log("D365 Response:", response.data);
        res.send("Success");
    } catch (error) {
        console.error("Integration Error:", error.message);
        res.status(500).send("Failed");
    }
});

Flow
External System → API → Logging → Dynamics 365

We had one case where everything worked in staging but failed in production due to authentication differences.

⚠️ Challenge #4: Performance Issues Show Up Late
What actually happens

Everything works — but slowly.

Reports lag
Pages take time
Queries feel heavy
Why it happens
Poor query design
Missing indexes
Large data volume
How it affects developers

You get blamed for performance, even when logic is fine.

How to fix it
Optimize queries early
Test with real data
Monitor during UAT
Example

SELECT CustomerId, SUM(Amount)
FROM Transactions
WHERE TransactionDate > '2024-01-01'
GROUP BY CustomerId

Simple View
Bad → Full Table Scan Good → Indexed Query
⚠️ Challenge #5: Testing Is Always Underestimated
What actually happens

Testing gets rushed. Issues show up after go-live.

Why it happens
Deadlines
Overconfidence
Lack of real-world scenarios
How it affects developers

Fixing things in production is always harder.

How to fix it
Test edge cases
Involve real users
Simulate actual workflows
Example

def test_empty_customer():
    assert migrate_customer(None) == "Error"

def test_duplicate_entry():
    assert migrate_customer(existing_customer) == "Handled"

Flow
Dev Testing → UAT → Real Usage → Production

Most real issues only showed up when users started using the system in ways we didn’t expect.

🟣 Key Takeaways
Migration issues are often data-related, not code-related
Customizations need rethinking, not copying
Integration problems are easy to miss
Performance needs early attention
Testing saves time later
🔵 Closing

If you’ve worked on a migration project, you already know — things rarely go exactly as planned.

But after a while, you start noticing patterns. The same types of issues keep coming up.

Curious to hear — what’s something unexpected you ran into during a migration?

Ultimate Guide to Construction ERP in 2026: What Works, What Doesn't and How to Choose the Right System

Zara Siddiqui — Fri, 20 Mar 2026 12:04:45 +0000

I've seen construction companies spend months selecting an ERP, only to struggle with it within weeks of going live. Not because the software was wrong, but because expectations were.

ERP in construction isn't just a technology decision. It's an operational shift. If your processes are unclear, your data is messy, or your teams aren't aligned, the system will reflect that very quickly.

That said, when it's done right, the impact is real. Better visibility, fewer surprises, and tighter control over costs. The kind of control most companies try to achieve with spreadsheets but rarely do.

What ERP actually means in construction

At its core, ERP is where your financials, projects, and operations meet.

In construction, that means:

your job costing connects directly to your accounting
your billing reflects actual project progress
your procurement and subcontractor data flows into finance without manual work

It sounds straightforward. In practice, it rarely is.

Most legacy setups break this connection. Finance works in one system, project teams in another, and reporting becomes a manual exercise. ERP, when implemented properly, closes that gap.

When do you really need an ERP?

Not every construction company needs one immediately.

If you're running a handful of projects, spreadsheets and basic accounting tools can still work. You'll feel some friction, but it's manageable.

The shift usually happens when:

you're managing multiple projects at once
job costing starts getting inconsistent
billing becomes harder to track accurately
reporting takes too long or feels unreliable

At that point, the issue isn't efficiency. It's control.

That's where ERP starts to make sense.

Features that actually matter (and the ones that don't)

A lot of ERP conversations get lost in feature lists. In construction, only a few really make or break the system.

Job costing in real time
Not after the project ends. Not in a separate report. You need visibility while decisions still matter.

Construction billing
AIA billing, milestone billing, retainage. These aren't edge cases. They're core operations. If your system can't handle them cleanly, you'll end up working around it.

Change order tracking
This is where margins are often won or lost. The system needs to track changes without breaking financial visibility.

Subcontractor management
Payments, compliance, tracking. It all needs to tie back into the financial side without duplication.

What doesn't matter as much early on is over-automation. Many companies try to automate everything from day one. It usually slows things down. Getting the fundamentals right first works better.

What's changing in 2026

The biggest shift isn't technology. It's expectation.

Companies don't just want software anymore. They want clarity.

Cloud ERP has become standard now, not because it's trendy, but because it simplifies access and reduces infrastructure overhead.

Integration is another area that's matured. Businesses are less tolerant of disconnected systems. They expect finance, projects, CRM, and reporting to work together without constant intervention.
There's also more focus on forward-looking insights. Not perfect forecasting, but better visibility into where things are heading - cost overruns, cash flow pressure, delays.

And then there's usability. If site teams and project managers don't use the system, it doesn't matter how powerful it is. Adoption has become just as important as capability.

What actually works

From experience, the companies that succeed with ERP tend to follow a similar approach.

They keep the initial scope focused. Finance, job costing, and billing come first. Everything else builds on that.

They invest time in cleaning their data before migration. Not perfectly, but enough to avoid carrying forward years of inconsistency.

They choose systems that fit their operations, not just their ambitions. There's a difference between what you might need in five years and what you can realistically implement today.

And they work with teams that understand construction. Not just the software, but how projects actually run.

This is something we've seen consistently at Dynamic Netsoft. The technical side matters, but understanding workflows-retainage, subcontracting, billing cycles-matters more.

What doesn't work

Over-customization too early is a common mistake. Trying to replicate every legacy process inside a new system usually leads to complexity without real benefit.

Rushing implementation is another. ERP takes time. Not because the software is slow, but because aligning processes takes effort.

And then there's the assumption that the system will fix operational issues. It won't. It will make them more visible.

Choosing the right ERP

There's no single "best" ERP for construction. It depends on your size, complexity, and how you operate.

Some systems work well for mid-sized companies looking for flexibility and integration. Others are better suited for large enterprises with complex requirements.

What matters more than the name is fit.

Can it handle your billing structure?
Does it support how you manage projects?
Will your team actually use it?

If those answers are clear, you're in a good place.

Final perspective

ERP in construction is less about software and more about discipline.

The right system won't just give you reports. It will give you confidence in your numbers. And that changes how decisions get made.

The companies that benefit the most aren't the ones with the most advanced systems. They're the ones that implement something practical, use it consistently, and improve over time.

That's what actually works

Most property management tools work fine… until you scale. The real problems don’t start at 10 units. They start at 1,000. Here’s what actually breaks and how to fix it.

Zara Siddiqui — Wed, 18 Mar 2026 09:56:10 +0000

Why Property Management Software Breaks at Scale and How to Fix It

Zara Siddiqui ・ Mar 18

#saas #realestate #architecture #erp

Why Property Management Software Breaks at Scale and How to Fix It

Zara Siddiqui — Wed, 18 Mar 2026 09:51:47 +0000

When you manage 10 properties, almost any tool works.

A spreadsheet, a basic app, or even manual tracking can get the job done. Rent is simple, tenants are few, and operations are manageable.

But something interesting happens as you grow.

At around 50 to 100 units, things start to feel messy.
At 500 units, systems begin to break.
At 1,000 and beyond, the problem is no longer software features. It becomes a system design problem.

This is where most property management tools fail.

The Early Stage: Why Simple Tools Work

In the beginning, property management is straightforward.

You need:

Rent collection
Tenant communication
Basic lease tracking

Tools like Innago or similar platforms are built exactly for this stage. They are simple, easy to use, and require almost no setup.

The reason they work well is because your data is still small and centralized. You are not dealing with complex ownership structures or financial reporting.

At this stage, simplicity is an advantage.

The Growth Stage: Where Problems Start

As your portfolio grows, the cracks begin to show.

You now deal with:

Multiple properties
Different lease structures
Maintenance workflows
More financial transactions

Most mid-level tools try to solve this by adding features. You get dashboards, automation, and accounting modules.

For a while, this works.

But the core issue is still hidden.

These systems are not designed for scale. They are designed for convenience.

The Real Problem: Data and Structure

At scale, property management is not just about managing tenants. It is about managing structured data across multiple layers.

Think about what changes as you grow:

Multiple legal entities
Different financial rules per property
Consolidated reporting requirements
Compliance and audit needs

This creates a data problem.

Most tools store information in a flat or loosely structured way. That is fine for small portfolios, but it breaks when you need:

Cross-property reporting
Consolidated financials
Audit-ready data
Real-time insights

At this point, adding more features does not fix the issue.

You need a different system architecture.

Why Mid-Market Tools Hit a Ceiling

Platforms like DoorLoop, Buildium, or AppFolio are great for growing portfolios. They improve efficiency and reduce manual work.

But they are still built as standalone systems.

They handle:

Tenants
Payments
Basic accounting

What they struggle with:

Multi-entity financial structures
Advanced contract workflows
Deep integration across business functions

This is why many operators feel stuck after a certain point. The tool works, but the business outgrows it.

The Enterprise Shift: From Tools to Systems

At larger scale, the mindset has to change.

You are no longer choosing a tool. You are building a system.

This is where enterprise platforms like Yardi or RealPage come in. They are designed for large portfolios and offer more advanced capabilities.

However, they can be expensive and sometimes rigid, especially if your business has unique workflows.

The Missing Layer: Connecting Operations and Finance

One important shift that often gets overlooked is the need to connect property management with core business functions.

At scale, property operations are tightly linked to:

Financial management
Contract lifecycle
Vendor management
Performance reporting

When these are handled in separate systems, it creates inefficiencies and data silos.

This is where ERP-based approaches come into play.

Where Solutions Like Dynamic Netsoft Fit

Platforms built on Microsoft Dynamics 365 take a different approach. Instead of focusing only on property-level activities, they connect the entire business.

For example, solutions developed by companies like Dynamic Netsoft are designed to handle real estate operations alongside finance, contracts, and reporting in a single system.

This allows businesses to:

Manage multiple entities with proper financial control
Track contracts and compliance more effectively
Get real-time visibility into performance
Scale across regions without breaking systems

The key difference is that these systems are not just tools for managing tenants. They are built as business infrastructure.

A Simple Way to Think About It

You can break it down like this:

Small scale: You need a tool
Growing scale: You need a platform
Large scale: You need a system

Most problems happen when businesses try to use a tool where a system is required.

How to Avoid Hitting the Wall

If you are currently managing a small portfolio, simple tools are fine.

But if you are planning to scale, it helps to think ahead.

Ask:

Can this system handle multiple entities?
Does it support financial consolidation?
Can it integrate with other business functions?

If not, you will likely outgrow it.

Final Thoughts

Property management software does not fail because of missing features.

It fails because it was never designed for scale.

The shift from 10 to 10,000 units is not just growth. It is a change in how your business operates.

The sooner you recognize that, the better decisions you can make.

Because in the long run, the system you choose is not just software.

It becomes the foundation of how your business runs.

Why Most Construction Companies Struggle with ERP (And What Actually Works)

Zara Siddiqui — Tue, 17 Mar 2026 08:35:11 +0000

If you talk to most construction or real estate teams about ERP, you’ll hear a familiar story.

The system was implemented with high expectations. It promised better control, improved visibility, and smoother operations. But somewhere along the way, things didn’t go as planned.

Teams still rely on spreadsheets. Project data feels disconnected. And the ERP ends up being used more for reporting than for real decision-making.

This isn’t uncommon. In fact, it’s one of the most frequent challenges I see in this space.

The Problem Isn’t the ERP Itself

It’s easy to assume the software is the issue. But in most cases, the real problem is how the ERP fits into the business.

Construction and real estate operations are not static. Every project is different. Costs shift, timelines change, and coordination happens across multiple teams and stakeholders.

When an ERP is implemented like a standard finance system, it struggles to keep up with this level of variability.

The result is a system that technically works, but doesn’t reflect what’s happening on the ground.

Where Things Start Breaking Down

One of the first signs is poor visibility.

Project managers don’t fully trust the numbers. Finance teams are working with delayed or incomplete data. By the time reports are generated, the situation on-site has already changed.

Another common issue is process disconnect.

Procurement, project execution, and finance are all happening, but not in sync. This leads to delays in billing, confusion around costs, and difficulty tracking profitability at the project level.

And then there’s adoption.

If the system feels too complex or doesn’t match how teams actually work, people start avoiding it. They fall back to familiar tools, which defeats the purpose of having an ERP in the first place.

What Actually Works in Practice

The companies that get value from ERP don’t treat it as just a system. They treat it as a way to align operations and financials.

Instead of forcing everything into rigid structures, they focus on making the ERP reflect real workflows.

That usually means connecting project activities directly with financial data.

When a project update happens, it should immediately impact budgets, forecasts, and reporting. Not after manual updates or adjustments.

It also means simplifying how teams interact with the system.

If site teams can easily update progress, track resources, and manage tasks without friction, adoption improves naturally.

The Role of Integration

Another shift I’ve seen is the move toward connected systems.

Rather than trying to make ERP do everything, companies are integrating it with tools that handle specific needs like scheduling or field operations.

ERP then acts as the central layer where all critical data comes together.

This approach allows teams to maintain flexibility without losing control.

A More Practical Way to Think About ERP

Instead of asking, “Which ERP is the best?”, a better question is:

“Does this system reflect how our projects actually run?”

Because that’s where most implementations succeed or fail.

A system that aligns with your workflows will always deliver more value than one with more features but less relevance.

Final Thought

ERP in construction and real estate is not about automation alone. It’s about clarity.

When your system gives you a clear view of what’s happening across projects, finances, and operations, decisions become easier.

And in an industry where small delays can turn into major costs, that clarity makes all the difference.