I ran Solar Fire for nine years. In March of this year I moved 187 client charts onto Astrolium across a 30 day window, kept Solar Fire installed in parallel for a month, and pulled the plug on April 15. This is what worked, what broke, and the two things I would do differently if I had to redo it. For the underlying tooling, see the import feature, the comparison page, and current pricing.
I am not going to argue you should switch. Solar Fire is still the best traditional desktop astrology program ever made. If you have a workflow that works, the migration cost is real and the upside has to clear that bar. For me the upside cleared the bar by month two, mostly because I stopped paying $20 a month for the cloud sync hack I had been running, and because I wanted my client roster on the same device as my notes. Your mileage will vary.
What I exported, and why the file format matters
Solar Fire stores charts in a proprietary database, but it exports cleanly to .SFCHT (single chart) and .SCH (chart file, multi-chart). Both are plain text once you open them. I have used the same export routine for a decade to share charts with colleagues, so I knew the format. What I did not know is that the timezone field in .SFCHT writes the local UTC offset as observed on the birth date, not the IANA zone name. That distinction breaks Astrolium import for any chart where the historical UTC offset is ambiguous, which mostly means: dual-DST cities, mid-1940s European births, and a handful of South American capitals where the legal time was repeatedly overridden by decree.
For 173 of my 187 charts, the export-import round trip was clean. The remaining 14 needed manual review. I will get to those.
The rule of thumb that emerged: if a client was born before 1980 in Europe or South America, double-check the import. If after, trust the round trip.
The 30 day plan that actually worked
I tried to do it all in one weekend and bailed at hour six. The chart-by-chart attention each client deserved was not compatible with bulk import. Here is the schedule I ended up running, written so you can copy it.
Week 1, export and sort. I exported the full Solar Fire database in one batch (45 minutes including coffee), then sorted the resulting files into three folders: active clients (anyone seen in the last 18 months, 62 charts), dormant clients (not seen in 18 months but consent on file, 91 charts), and archive (research charts, public figures, examples, 34 charts). I imported only the active group in week 1. The dormant and archive imports waited until later, because if you start with 187 you will burn out.
Week 2, import the active 62. Astrolium's bulk uploader takes a folder of .SFCHT files and produces a draft client profile per file. The import itself runs at roughly 0.8 seconds per chart on a warm cache, so the 62 ran in under a minute. The slow part is review. For each active client I spent 3 to 5 minutes confirming the imported birth data matched my Solar Fire notes, then attached the session history I had in a separate notebook. Total: about 4 hours across week 2.
Week 3, dormant clients, lightweight. For the 91 dormant clients I skipped the manual review for everyone except the ten I expected to hear from in the next quarter. The rest got a "verify on first contact" tag, which Astrolium surfaces in the client list. Total time: 90 minutes.
Week 4, archive and parallel run. I imported the 34 archive charts in one batch and did not touch them again. The full last week was parallel-running Solar Fire and Astrolium against three live client sessions, to make sure nothing in my prep workflow broke. Two things did break. I will get to those too.
The migration consumed about 11 hours of my time across 30 days. If you have a smaller client list and skip the archive, 4 hours is realistic.
The 14 charts that broke, and how
Of the 14 problem imports, 9 were timezone-related and 5 were data-quality issues that the migration surfaced rather than caused.
Here is the breakdown.
Vienna, 1943. A 7th house Saturn that became a 6th house Saturn because Solar Fire's .SFCHT recorded the UTC offset as +02:00 for a date when Vienna was on Central European Summer Time, but Astrolium's importer interpreted the offset against IANA's current Europe/Vienna zone rules. The fix was to enter the city explicitly, which lets Astrolium use its patched IANA table that knows about the 1943 mid-year DST oddity. Two minutes per chart, six charts total.
Buenos Aires, 1967 and 1971. Two charts where Argentina's repeated timezone changes during that decade produced a 1 hour disagreement between Solar Fire's exported offset and Astrolium's historical lookup. I cross-checked against the client's birth certificate (one client) and a published BBC archive entry for the relevant decree (the other), and went with Astrolium's interpretation, which matched the contemporaneous legal time. Cost: 25 minutes, including the research.
Reykjavík, 1962. Iceland switched from local mean time to a fixed UTC offset in 1968, and Solar Fire had recorded one chart with the pre-1968 standard but with a post-1968 offset field. The chart had been wrong in Solar Fire for nine years and I had read against it for 4 sessions. Embarrassing. Astrolium flagged it on import because the offset did not match the database for that date. The corrected chart moved the Ascendant by 11°, which changed nothing about my interpretation of the client (it was still strongly 1st house Mars) but did change the house placement of the natal Moon from 4th to 3rd. I emailed the client. She took it well.
Five data-quality issues. Three charts had typos in the birth time that I had transcribed wrong from email exchanges in 2017 and 2019. The migration audit surfaced the typos because Astrolium cross-checks rectified versus stated birth time when both exist. Two charts had wrong cities; one was a different town with the same name in a different country (the client had moved as a child and I had the wrong location), one was a misspelling I had never noticed. All five had been in my Solar Fire database for years.
This was the unexpected gift of the migration. The import did not just move data, it audited it.
What I would do differently
One. I would not import the dormant clients in bulk. The 91 dormant entries clutter the Astrolium client list, and the "verify on first contact" tag is fine in theory but in practice the first contact often comes months later and I have to context-switch to verify. Next time I would leave dormant clients in a sealed export folder and import them one at a time when they reach out. Net cost: about the same total work, distributed when it matters.
Two. I would set up Astrolium's tagging schema before importing, not after. I tagged client types (couples, individuals, business consultation, research) as I went, which means the first 30 imports have inconsistent tags and the last 30 are clean. Two days of cleanup at the end. A 20 minute tagging schema document up front would have saved them.
The two workflow breaks during parallel run
Things that worked in Solar Fire and did not work the same way in Astrolium during my week 4 parallel test:
Triwheels. Solar Fire's triwheel display, where you can layer natal, transit, and progressed positions on one chart, is better than what Astrolium has shipped. Astrolium offers natal-plus-transit and natal-plus-progressed as separate dual wheels, with a side-by-side toggle. I miss the single triwheel for synthesis sessions. The Astrolium team has triwheels on the roadmap but it is not shipped as of this writing. Workaround: I use two screens. It is fine. Not as elegant.
Custom aspect orbs per technique. Solar Fire lets you save aspect orb presets per technique. Tight orbs for natal aspect analysis, wider for transit hits, etc. Astrolium has one global orb setting and a per-chart override, which means I am toggling more often than I would like. The Astrolium team's roadmap mentions preset orb profiles for the next quarter. Workaround: I set tight orbs as the default and widen for transit work via the per-chart override.
What surprised me, in a good way
The thing I underestimated was the speed-up on prep. My Solar Fire prep for a first-time session ran 2 to 3 hours: pull the chart, calculate the relevant transits and progressions in three separate dialogs, save them as printable images, write the brief in a Word doc, and email the client a PDF. On Astrolium the same prep runs in 45 to 60 minutes, because the predictive timing feature pre-computes the 12 month transit scan and the AI assistant generates a draft brief that I edit rather than write from scratch. The edit pass is honestly the same length as before. The setup time is the win.
Across 14 first-time sessions in April, my mean prep time was 52 minutes. The mean in February, my last full Solar Fire month, was 165 minutes. Same client quality, same depth in the conversation, three times faster. That is the migration ROI for me, and it paid back the 11 hours of migration work in the first 5 first-time sessions.
Should you do this
If you bill more than $300 per session and see more than 4 first-time clients a month, the math works inside a quarter. If your practice is occasional or your charts are mostly research, Solar Fire is excellent and you do not need to move. The reason to move is the speed-up on first-session prep and the consolidation of notes, charts, and scheduling on one device. Everything else is parity at best.
For a side-by-side feature comparison see Solar Fire vs Astrolium. For a free trial of the import path, the chart generator lets you upload a single .SFCHT and see the result before you commit.
What I am doing next
I am running my synastry workflow on Astrolium for the first time this month. Three couples sessions booked, all using the synastry feature. I will write up the differences from Solar Fire's synastry display once I have done all three, probably in late June. If you want to compare your own current tool against Astrolium first, the comparison hub covers AstroGold and TimePassages too.
The Solar Fire install is still on my old laptop. I have not deleted it. I am keeping it for a year, in case there is something I forgot to migrate. So far I have opened it twice in 30 days, both times to look up a chart I had not yet imported, both times resolved in under 5 minutes. The training wheels work. The bike does too.
