How to Move a CMiC BI Query to a Different Data Source Without Rebuilding It
Updated: 5 days ago
If you need to move a CMiC BI query into a different data source — from test to production, between companies, or after a database refresh — you do not have to rebuild it. Export the query from Query Builder, re-import it, and reassign the data source during import. The full query configuration comes along intact.
The steps are short. Two of them are easy to miss, and missing either one is why this task has a reputation for being harder than it is.
Why would you need to change a BI query's data source?
Four situations account for most of it:
Promoting from test to production. You built and validated the query against a test data source and now need it pointing at live data.
After a database refresh or environment rebuild. The data source your query referenced no longer exists under the same definition.
Creating or reorganizing data sources. The data source your query referenced no longer exists under the same definition or you created a new data source and need to move it.
In each case the alternative - rebuilding the query by hand in the destination environment - is slow and introduces differences you will not notice until someone questions a number.
How the export and import actually works
In CMiC, Query Builder lives under BI in the application selector. Export is a two-part motion that trips people up the first time: you open the query, then click Edit Query, and only then does File → Export become available. Exporting from the search results list alone will not do it.
The export produces a small .bi file - typically a couple of kilobytes - that carries the query definition rather than the data.
To bring it back in, you use File → Import, browse to the .bi file, and CMiC presents three options.
The three import options, and when to use each
Original data source. Re-imports the query pointing at whatever data source it was built against. Use this when you are restoring a query into the same environment it came from, or moving it between systems where the data source is defined identically.
Change data source. Reassigns the query to a data source you select during import. This is the one you want for test-to-production promotion and for sharing across environments.
Replace an existing dashboard. Overwrites a dashboard already in place rather than creating a new object. Useful for updating something already in users' hands, and worth treating carefully for exactly that reason.
The step almost everyone misses
When you choose Change data source and click the magnifying glass to pick a destination, the search dialog opens with the Name field pre-populated with the original data source name.
Search from that state and you get exactly one result back — the data source you are trying to move away from. It looks like the environment has no other options available.
Clear the Name field first, then click Search. The full list appears: CMiC Default Data Source and whatever else is defined in your environment. Select the destination, click OK, and confirm.
That single pre-populated field is responsible for most of the confusion this task generates.
What if the destination data source still isn't listed or you get an error?
If that happens, resist the obvious move. Building a replacement data source by hand in the destination environment feels like the fix and is the thing that will cost you the afternoon.
The reason comes down to how CMiC identifies a data source. Internally it goes by a generated ID, not by the name on the screen. When you export a query, that ID rides along inside the .bi file - so the file is not requesting "a data source called Job Cost." It is requesting one particular data source, by number.
Hand-build a new one in the target environment and it gets its own number - which still doesn't help. Match the name exactly, mirror every property, and the system still treats it as a different object entirely. Nothing in the interface explains this. You just find that the remap choice never appears and the import keeps refusing.
Carrying the data source across, rather than reconstructing it, is what actually clears the problem. Catalogue Builder can export a data source from one environment and load it into another with its identity preserved. With the same number on both sides, the query file locates what it expects and imports without complaint.
Sequence matters here: the data source has to land in the destination before the query does. Most teams work this out only after hand-building three or four data sources and watching every one of them fail the same way.
The other thing to watch
The import dialog carries a warning in orange that is easy to read past: "Imported query/dashboard is not saved automatically."
Completing the import does not persist the query. If you close out without saving, the work is gone and you get to do it again. Save before you navigate anywhere.
Download the step-by-step guide
We put the full click-by-click walkthrough into a PDF, with screenshots of every dialog. It covers opening Query Builder, exporting the original query, importing the file, and reassigning the data source.
When this stops being a tips-and-tricks problem
Moving one query is a ten-minute task. Moving a reporting library is not.
If you are migrating dozens of queries and dashboards between environments, the individual steps stop being the hard part. The hard part is that data sources are rarely structurally identical across environments - column availability differs, security models differ, and a query that imports cleanly can still return numbers that are quietly wrong. Nothing in the import process will tell you that. You find out when a project manager disputes a cost report.
That validation work - confirming a migrated query returns the same answer against the destination data source that it did against the original - is the part that actually takes expertise, and it is the part that gets skipped under schedule pressure.
We do this work for general contractors, specialty subcontractors, and heavy civil firms, usually as part of a broader environment migration or BI cleanup. Our founder is an Oracle ACE award recipient with over a decade of experience programming on CMiC, which is relevant here for an unglamorous reason: most CMiC reporting problems are database problems in disguise.
Get in touch if your reporting library needs to move or you would like CMiC BI training. We offer all levels of courses from beginner to advanced with specialty topics such as performance tuning and passing context into the queries so your users get only the data they need and they get it faster. We welcome you to bring as many staff members as you like and recording to make sure you get the most from our sessions.
Training Offerings
We are pleased to offer a variety of training programs designed to enhance skills and knowledge in our field. Our training sessions are tailored to meet the needs of different audiences, from beginners to advanced professionals.
Available Training Programs
Introductory Courses: Perfect for those new to the industry.
Advanced Workshops: For experienced professionals looking to refine their skills.
Certification Programs: Gain recognized credentials to boost your career.
Custom Training: Tailored sessions to meet specific organizational needs.
Training Formats
In-Person Workshops: Hands-on training with expert instructors.
Online Training: Interactive sessions covering various topics.
How to Enroll
To enroll in any of our training programs, please Get in touch.
Where to go for official CMiC documentation
For product documentation, release notes, and version-specific behavior, CMiC Assist is the authoritative source and should be your first stop. This guide reflects how the feature behaves in the environments we work in; your version may differ and the programs change over time.
Impact Integrated Technology is an independent CMiC implementation and consulting firm based in Murrieta, California. We do not resell CMiC and we are not compensated by the vendor.
Comments