Read on Twitter
A lot of people are upset about this, but there are probably good technical reasons for this. I& #39;m working on re writing an 17ish year old system and there are major technical hurdles to overcome. 
https://abs.twimg.com/emoji/v2/... draggable="false" alt="🧵" title="Thread" aria-label="Emoji: Thread"> https://twitter.com/wizards_magic/status/1254787393309143042">https://twitter.com/wizards_m...
I obviously cannot speak to technical aspects of the Magic application, but here& #39;s some bits from my experience. Applications are not built the same way they used to be. Everything from database structure to security to UI, it& #39;s a whole new ballgame.
Older databases tend to not be developed to the same standards we use today, and they often have 10+ years of shoddy bandaids patching major gaps in the original conception.
Our system we& #39;re replacing has a TAX_YEAR column, but also a TAX_YEAR_NEW, a TAX_YEAR_TY, and a TY_TAX_YEAR column from years of patching. Which column is the definitive tax year? Is there a definitive tax year or do different parts of the app use different ones?
Now on the code layer, all those tax year columns are strung together across years of functionality with cooked spaghetti in a language only one or two people in our office still know. And this is only _one_ piece of data. We& #39;re replacing a system an entire office uses daily.
Migrating data means knowing which tax year the spaghetti is looking at without breaking the spaghetti and while paying homage to the soul of the guy who developed it in case it& #39;s cursed. The data migration process for this app is in its third year.
Software developer time is not cheap time. Paying several people to work on migrating the data across several years, on top of operational costs is a very expensive process in both time and and money. If we could not migrate data, we absolutely would not.
Also, rewriting legacy apps are very difficult on a lot of levels. It& #39;s a system people know. By proposing to rewrite it you& #39;re suggesting that it& #39;s wrong in some way, which makes people upset. There& #39;s a huge emotional component, when people have been using a thing for years.
But the reality is often that older apps aren& #39;t up to today& #39;s security needs and standards. Even if we& #39;re ok with old UI and patched databases, does that system contain any sensitive information? Even information that& #39;s not technically sensitive you might not want getting hacked.
By keeping old systems live even for archival reasons there may be sensitive data hanging out waiting to be hacked. Updating the system for security updates might take as long as writing a replacement system, without the benefits of better UI and database structure.
Asking for the ability to download the data can be as difficult as migrating data. You have to know which pieces of data are relevant and how they& #39;re connected. It may not be consistent across the years and across updates. Again, it can be a very long and expensive process.
This thread brought to you by the trauma of rewriting an old system.
Say a prayer for the souls of the developers doing this thankless labor to protect your data and update your customer experiences.
Say a prayer for the souls of the developers doing this thankless labor to protect your data and update your customer experiences.
