Moving FAX Orders to the Web ── Designing the Dual-Operation Period and a Phased Migration

In the previous article, “What Is EDI? How It Eases Order Processing Between Companies,” we looked at the mechanism that replaces manually re-entering orders received by FAX or email with data exchange between systems.

This article is a sequel to that one. The theme moves one step past “understanding the mechanism” to how to actually migrate.

Requests to “move FAX orders to the web” usually continue like this:

“But some of our trading partners can only use FAX.”

“We want to keep using our current sales management system as-is.”

“We can’t afford to have orders stop during the switchover.”

In other words, the real-world challenge isn’t building a web ordering system. It’s designing the period during which orders gradually shift to the web while FAX remains in use.

This article organizes the move to web-based FAX orders around four themes: designing the dual-operation period, CSV import as an intermediate form, preparing product and customer master data, and how to bring trading partners on board.

1. The Conclusion, Up Front

The key points when planning a move from FAX orders to the web are as follows:

• Set the goal not as “abolishing FAX” but as “reducing the number of orders that require manual entry”
• Assume a dual-operation period of FAX and web will always occur, and design its duration and how to measure it in advance
• Keep multiple intake channels if needed, but consolidate internal order processing into a single pipeline
• Don’t demand web-form data entry right away — provide CSV import as an intermediate form
• Because the web ordering screen exposes product and customer master data directly to trading partners, prepare that master data first
• Don’t switch all trading partners at once — classify them by order volume and willingness to cooperate, and migrate them in order

JIPDEC also points out that when manual processes like FAX and phone remain, staff are still needed to handle them, making it hard to fully realize the benefits of efficiency gains. That’s precisely why the dual-operation period should not be left as “something that unavoidably happens,” but should itself be treated as an object of design — one whose duration is deliberately shortened.

2. Why an All-at-Once Move to the Web Tends to Fail

Moving FAX orders to the web has a characteristic that can’t be decided by internal system convenience alone: it’s the trading partner who places the order.

An approach that announces to every trading partner, “please place orders on the web starting next month,” tends to lead to failures like these:

• Trading partners who can only order by FAX stop being an “exception” and become an “obstacle to the plan”
• Every trading partner’s circumstances differ, yet the same deadline gets imposed on all of them
• Partners who don’t migrate keep sending orders by FAX indefinitely, so the dual-operation period becomes permanent
• The project gets judged as “we moved to the web, but headcount didn’t drop,” and stalls

The root cause is setting the goal as “eliminating FAX.”

Replacing that goal with “reducing the number of orders that require manual entry” makes the plan realistic. For example, if only the top trading partners — who account for 70% of orders — migrate to web or CSV, data entry work drops significantly even if the remaining 30% stay on FAX.

Rather than moving everything at once, move the highest-impact parts first. That’s the basic idea behind a phased migration.

3. What the End State Looks Like ── Multiple Entry Points, One Internal Pipeline

Before designing the phased migration, it helps to first picture the target shape.

The key is to think of the intake channel and the order-processing pipeline as separate things.

[Intake channels]                [Shared order data]          [Internal processing]

FAX ──── staff enters data ──┐
Email attachment ── staff enters data ─┤
CSV import ─── automatic import ────┼──→ Order data ──→ Inventory allocation, shipping, billing
Web order screen ── automatic registration ───┘   (unified format)

No matter how many intake channels exist, as long as the format and processing of the order data downstream are consolidated into one pipeline, downstream processes like inventory, shipping, and billing keep running on a common flow.

Conversely, if you build separate processing or separate ledgers per channel, operations get more complex with every new channel, and the burden of dual operation keeps growing.

Even orders that arrive by FAX should become the same order data as the other channels once a staff member has entered them. Migration, then, is the work of shrinking the count flowing through the “staff enters data” row in this diagram and growing the count flowing through the “automatic import” / “automatic registration” rows.

You don’t necessarily need to overhaul your existing sales management system. As long as you can confirm whether you can add an entry point for order data (a CSV import feature, database integration, an API, etc.), you can proceed while keeping your current setup intact. This confirmation point is exactly what we covered in the previous article’s “Confirm the connection to your internal system”.

4. CSV Import as an Intermediate Form

Asking trading partners to jump straight from FAX to web-form data entry can be a heavy burden for them.

From the ordering side’s point of view, web-form entry means “typing the order data they already created in their own ordering system or in Excel into someone else’s screen, a second time.” If a trading partner is already generating order data through their own systems, having them hand over the file as-is and importing it means less work on both sides.

So, as an intermediate form, we prepare CSV (or Excel) import.

Stage 1: Receive the CSV as an email attachment, and have staff load it using the import feature
Stage 2: The trading partner uploads the CSV from a web page, and it's imported automatically
Stage 3: Standardized trading partners move to a web order screen or EDI

Even at Stage 1, data entry time and transcription errors drop significantly compared to manually typing while looking at a paper order. Another advantage is that it’s easier to get cooperation, since the change on the trading partner’s side amounts to little more than “switch what you were sending by FAX to an email attachment instead.”

When designing CSV import, decide at minimum the following items:

CSV looks simple, but it’s a format with plenty of pitfalls around character encoding, line breaks, and how commas and quotation marks are handled. Technical points to watch when implementing import processing are covered in our “Practical Guide to CSV File Handling”.

Note that CSV import isn’t the final form — it’s an intermediate one. The field definitions and code scheme you decide here go on to form the foundation for later web ordering or EDI as well.

5. Prepare Product and Customer Master Data First

With FAX orders, staff absorb the gaps in master data.

For example, even if an order sheet lists an old product name, staff read it as “this means the current version of this product” and enter it accordingly. Even if the unit is written as “case,” they remember how many pieces are in a case and do the conversion.

Once you move to CSV import or web ordering, a machine has to perform that same reading-between-the-lines. What’s more, on the web ordering screen, the product master data is exposed directly to the trading partner.

For that reason, at minimum the following preparation is needed before migration:

• Cleaning up product codes (retiring discontinued items, merging duplicates, creating an old-to-new code mapping table)
• Standardizing product name notation (are the names presentable to trading partners?)
• Units and pack quantities (the relationship between individual units, cases, and pallets, and minimum order quantities)
• Trading partner codes and delivery destination codes (how to handle cases where one trading partner has multiple delivery destinations)
• Where to manage partner-specific pricing and contract terms

The important thing here is not trying to perfect all master data before starting. Waiting for that means the migration never begins.

The realistic approach is to first prepare only the range of products and delivery destinations handled by the first trading partner to migrate (the pilot), and expand that range each time you add another migrating partner. Build the master data preparation work itself into the phases of the migration.

6. Designing the Dual-Operation Period

Dual operation of FAX and web (CSV) will always occur during the migration period. Left undesigned, dual operation becomes the norm, and you end up in a state where “work increased by exactly as many channels as we added.”

Designing the dual-operation period specifically means deciding the following:

6.1. Set a duration and a target value

Decide numerically “by when, what proportion of orders should be automatically imported.” For example, something like “shift the FAX order ratio from 70% to 30% within six months.”

A dual-operation period with no deadline simply becomes permanent. Even if you don’t hit the target, having a deadline drives you to go check, partner by partner, “why isn’t migration progressing here?”

6.2. Measure counts by channel every month

Track migration progress by numbers, not by feel.

• Order counts by channel (FAX, email attachment, CSV, web)
• Number of manually entered orders and the time they took
• Number of import errors and their causes
• Number of data corrections and duplicate entries

This is the same thinking as the metrics worth tracking after go-live covered in the previous article. Measuring by channel makes visible “which trading partner is worth pushing on, for the biggest impact.”

6.3. Align operational rules across channels

Confusion during the dual-operation period tends to arise when business rules differ by channel.

• Is the order cutoff time the same for FAX and web?
• Which channel handles order changes and cancellations? (If an order placed on the web is changed by FAX, the two records need to be reconciled.)
• Does the notification process for out-of-stock items differ by channel?
• Is the order number unique across channels? (Needed to detect duplicate registrations.)

In particular, the pattern of “order on the web, then immediately change it by phone or FAX” will always occur. Decide in advance which channel handles changes, and who is responsible for correcting which data.

6.4. Treat FAX intake as an improvement target too

FAX will remain during the dual-operation period. If we accept it’s staying, the FAX-side process is also an improvement target.

• Receive FAX through a multifunction printer, convert to PDF, and stop managing paper
• Consolidate received PDFs into an order folder and manage processing status (unprocessed, entered, on hold)
• Link the entered FAX original (PDF) with the order data by order number, so they can be cross-checked later

Thinking “FAX will go away eventually, so we won’t touch it” doesn’t reduce the burden during the dual-operation period. Until migration completes, treat FAX processing as just one more channel merging into the same order data.

7. How to Bring Trading Partners On Board

Whether the phased migration succeeds depends more on how you engage trading partners than on internal work.

7.1. Classify trading partners

Don’t treat every trading partner the same — classify them first.

Groups A and B determine the impact. Trying to force group C to move costs a lot for little return, so it’s fine to tell them plainly, “we’ll keep accepting FAX from you.”

7.2. Choose one pilot partner

Rather than migrating multiple partners in parallel from the start, establish the operation with a single partner first. The selection criteria are the same as in the previous article:

• High order volume, so the impact is easy to measure
• Mostly routine, standardized orders
• Easy communication between staff on both sides, and understanding of system integration

With the pilot, build the “template” — CSV format, how to communicate errors, the master data mapping table, guidance documents — and reuse that template for the second partner onward.

7.3. Frame the guidance around the partner’s benefit

From the trading partner’s point of view, a change in ordering method is a request driven by your own convenience. Frame the guidance around the partner’s benefit, not your own efficiency gains.

• Order confirmations come back immediately, so calls to check “did it arrive?” are no longer needed
• Fewer mis-shipments and quantity errors caused by misreading
• They can look up their own order history and repeat orders more easily (for web ordering)
• No more FAX transmission work or resending failed transmissions

Practical consideration also pays off.

• Summarize the operating procedure into a single-page manual (aim for a scope that a few screenshots can explain)
• State the start date and the coexistence period explicitly (“we’ll start accepting web orders from month X; FAX will continue to work alongside it for now”)
• For the first several times, accept orders sent by either FAX or web, and respond to inquiries immediately

It’s also not advisable to lead with an announcement like “we will discontinue FAX as of month X.” It’s better to bring up the deadline only once migration has progressed and the remaining trading partners are down to a small number — that way you avoid damaging the relationship.

Regarding digitalization of order processing for small and medium enterprises, the Small and Medium Enterprise Agency introduces standardization efforts including common EDI formats, and their benefits. If your industry association or major trading partners already support such standards, it’s also worth considering aligning with a standard format rather than a proprietary one.

8. A Model Case for Phased Migration

Let’s organize everything so far into a chronological model. These durations are just one example and will vary with the number of trading partners and internal staffing.

Phase 0’s “assess the current state” can directly reuse the inventory of ordering methods introduced in the previous article.

Also, if you’re unsure whether to move order management itself to a web system or keep it as a desktop app, “Should You Move a Windows App to the Web?” lays out a decision framework. Moving the intake channel to the web and moving the internal system to the web are decisions that can be made independently of each other.

9. Common Stumbling Blocks and Countermeasures

Finally, here’s a summary of stumbling blocks that commonly arise during actual migrations.

Summary

Moving FAX orders to the web is less about building a system and more about designing the migration period.

• Set the goal as “reducing the number of orders requiring manual entry,” not “abolishing FAX”
• Multiple intake channels are fine, but consolidate internal order data and processing into one pipeline
• Don’t demand web-form entry right away — insert CSV import as an intermediate form
• Advance master data preparation in stages, starting from the scope of the first migrating trading partner
• Set a deadline and target value for the dual-operation period, and measure progress by channel counts
• Classify trading partners by volume and willingness to cooperate, build the template with one pilot, and then expand

As organized in the previous article, the benefit of EDI or web ordering is determined by how far the received data can flow through your internal operations. Designing the migration is the work of planning, in a reasonable order, how to grow the proportion of orders that merge into that flow.

For Those Considering Moving Order Processing to the Web

If you’re considering rethinking FAX orders but aren’t sure where to start — coordinating with trading partners, connecting to your existing sales management system, how to proceed with CSV formats and master data preparation — the place to begin is by organizing your current order counts by channel.

At KomuraSoft LLC, we can help with designing and implementing CSV import / web order integration that leverages your existing Windows business applications and databases, as well as organizing the migration plan itself.

Rather than assuming a full-scale system overhaul, we can also explore an approach that keeps your current sales management setup intact while adding intake channels in stages.

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.