Migrating quotes and quote history to EDGEBIC mostly means deciding not to: there is no quote import, and an old quoted date computed against infinite capacity is not a fact worth re-creating. In EDGEBIC by User Solutions the honest approach is to keep historical quotes in the old system as read-only records, re-enter only the quotes still live enough to win, and enter already-accepted quotes as jobs instead. Before any of that, fix the two cost settings that make a simulated quote meaningful.
Why the history does not travel
A quote in a finite capacity scheduler is not stored text. Its estimated dates, hours and costs come from simulating the work against your real plant: the shifts, the machines, and everything already committed. That is what makes the number defensible when a customer asks whether you can really hit it.
Which is exactly why an old quote cannot be meaningfully migrated. If it came from a system that planned against infinite capacity, its date was never checked against what the plant had promised. Typing it into the new system produces a number the engine would disagree with the moment you simulated it. There is also no quote import entity, so the question resolves itself.
Keep the old records available and read-only. That satisfies the real requirement, which is record-keeping, and it costs nothing.
What to do with each kind of quote
| Quote status | What to do |
|---|---|
| Closed, won or lost | Leave in the old system as read-only history |
| Open but stale, unlikely to convert | Leave it; re-quote if the customer comes back |
| Open and live | Re-enter and simulate against real capacity |
| Accepted, not yet a job | Enter as a job through the SalesOrder import mask |
Most shops find the third row is a small number, often under a dozen. That is the entire hand-entry job.
Migrate the customers, not the quotes
The part of quoting that genuinely needs importing is the customer master, and that has a mask. Bringing customers across means the relationships, contacts and references are all present, so re-entering a live quote is a matter of picking a customer rather than retyping one. Do it in the normal sequence covered in migrating your item and customer master.
Products matter here too, for a reason that is easy to miss: a quote is quoted against a product with a routing, so the routing is what makes a simulation possible. In effect, the product's routing is your reusable quote template, which is why there is no separate template concept to migrate. Get the routings right and every future quote inherits them.
Fix the two cost inputs first
This is the most common complaint on a freshly migrated system, and it is a setup issue rather than a quoting one. Estimated cost comes out far too low when either of these is missing:
- Work center rates. Labor cost comes from the rate on each production work center. A rate left at zero contributes nothing.
- Product unit costs, or material steps on the routing. Material cost comes from those. Without them, material falls back to zero.
Costing here covers labor and material, so those two inputs are the whole picture. Set them during the migration, not after somebody has sent a customer a price derived from them. Pair this with pricing a quote from the schedule.
Re-entering a live quote
The quote dialog collects what you would expect: the product, the customer and a customer reference, quantity, unit price, and a target start date, plus a scheduling direction. Forward asks when the work will finish if you start on that date; backward asks how late you can afford to start and still finish by it. A backward quote becomes a backward order when converted, so the real run reproduces the quoted plan.
Then simulate. Two behaviors are worth knowing while migrating:
- Simulating auto-fills the unit price only when it is zero, so a price you have already quoted a customer is protected rather than silently overwritten.
- The simulation does not touch the production schedule. It uses a temporary job that is removed afterward, which is why you can re-simulate as often as you like, as re-simulating a quote after a change describes.
When a quote is won, converting it creates one manufacturing order and marks the quote converted. Conversion is refused if the quote has already been converted or an order for it exists, so repeat business is a new quote rather than a second conversion of the old one.
What this changes for sales
Worth saying during training, because it is the visible difference. Previously a quoted date was an estimate produced independently of the shop's commitments. Now it is produced from them, which means two things. It will sometimes be later than sales would like, and it will be right more often. The reason a date moved is also findable, which is a better conversation than defending a number nobody can explain, and it is the argument in why quote against real capacity.
The takeaway
Do not migrate quote history to EDGEBIC: there is no quote import, and an old date computed without capacity is not worth re-creating. Keep closed quotes as read-only history, import the customer master and the product routings that make simulation possible, re-enter only live quotes, and enter already-accepted ones as jobs through the SalesOrder mask. Set work center rates and product unit costs before anyone quotes from the new system, since labor and material are where the cost comes from. See the platform on the EDGEBIC overview, the upgrade path on the RMDB to EDGEBIC guide, and pair this with what you do not need to migrate to EDGEBIC and the quote lifecycle from draft to converted.
Expert Q&A: Deep Dive
Q: Sales wants five years of quote history in the new system. How do we handle that conversation?
A: Separate the two things they are actually asking for, because only one of them is about the new system. The first is record-keeping: who was quoted what, at what price, and when. That is a genuine need and the old system already satisfies it, so keep it available read-only, exactly as you would keep any archive, and nothing is lost. The second is the implied request to re-create the estimates, and that is where the value falls apart. A five-year-old quoted date was computed by a system that did not know what your plant had committed, so re-creating it in a finite capacity scheduler would mean typing a number that the engine would immediately disagree with. The useful compromise is to migrate the customer master, which is importable, so the customer relationships and references are all present, then re-enter only quotes still open enough to win. Sales keeps the history where it lives and gains defensible dates on everything new.
Q: We have quotes the customer already accepted but that are not yet jobs. Quote or order?
A: Order, in most cases. A quote exists to answer whether you can hit a date and what it should cost, and once the customer has accepted, both questions are settled. Entering an accepted quote as a job through the SalesOrder import mask gets it into the plan directly, with product, quantity and dates, and it consumes real capacity where it belongs. Re-entering it as a quote first means simulating an estimate you no longer need and then converting it, which is extra steps for the same outcome. Two exceptions are worth noting. If the accepted price depends on a start date you have not yet confirmed, quoting first is genuinely useful because the simulation tells you whether the date still holds against current commitments. And if you want the margin figures on the quote record for reporting, entering it as a quote and converting it keeps the markup and unit price attached.
Frequently Asked Questions
Ready to Transform Your Production Scheduling?
User Solutions has been helping manufacturers optimize their production schedules for over 35 years. One-time license, 5-day implementation.
User Solutions Team
Manufacturing Software Experts
User Solutions has been developing production planning and scheduling software for manufacturers since 1991. Our team combines 35+ years of manufacturing software expertise with deep industry knowledge to help factories optimize their operations.
Share this article
Related Articles
Migrating to EDGEBIC: The Complete Guide
The full path from RMDB, EDGEBI, a spreadsheet, or a whiteboard to EDGEBIC: what carries forward, what is hand-built, the import order, and how to validate the first schedule.
Migrating Your Tools and Fixtures to EDGEBIC
Tools and fixtures are not one of the eight import masks, so you build the list by hand. Here is what to enter, the quantity rule that ruins schedules when it is wrong, and where tools belong in the migration sequence.
Rehearsing Your EDGEBIC Migration Load
The data load is a repeatable operation, not a one-shot event. Every entity type is safe to re-import, and a reset takes you back to an empty plant, so plan to load your data three times before go-live.