Hello This is my first week with cold fusion. My assigned project is to migrate a cluster of CF 2011/apache/tomcat servers from ubuntu 2014 to ubuntu 22 Right now, I'm at the stage of trying to understand the general architecture of CF and my site specific setup. I've poked around a bit and I'm guessing as long as I choose JRE versions that CF 2011 supports , this should be doable. Has anyone succeeded with a migration like this ?

By "CF2011" do you mean "CF11" or CF2021?

Hi Dan. The CF version you are referencing doesn't exist. Is it "CF11" or "CF2021"?

👊🏻

Too quick for me lol.

(for context, coldfusion used numbered versions from 1 to 11, and then for what would have been "12" they switched to using years.... So it goes "... 9, 10, 11, 2016, 2018, 2021, 2023....")

@Dan MacNeil let's use this thread.

CF11 , I'm 99% sure. (support ended 2019) yes, definitely 11 , not a year numbered one definitely

You might get an answer here but I don't know (and maybe Mark would know?) the likelihood that anybody around here has done this as we don't see a lot of CF11 (particularly clusters). I think in theory you're right, you just need a JRE that CF likes, but it's entirely possible that something will blow up along the way and you're swimming at your own risk with an EOL product. One thing you might do to simplify matters, assuming you're stuck keeping CF11, is to separate the front end -- put Apache (over there somewhere), or better yet NGINX, and then you're just dealing with Tomcat and CF in the migration. Or better still, if you can (and you may not be able to, without an Enterprise license) try Commandbox, which for my money is the easiest way to deploy CF anywhere

@Dan MacNeil Any work done on those servers needs to include a plan to update them to a supported version of CF. The security fixes enough should be enough to sell that. And yes, CommandBox can be used to help deploy CF either directly to the VM or inside of a Docker container.

I look forward to ColdFusion X's release.

That's the one coming after Elon Musk buys Adobe 😆

Extremely hardcore engineers use CF.

Not sure why that would be.

This is in the Elon Musk owned CF universe. You're safe for now.

This is a definition of "safe" I was heretofore unaware of.

Re ColdFusion X: We had ColdFusion MX and Adobe had the sense to change it back.

Yeah, Macromedia was all in on the MX. I was part of a small startup called MX Foundry that was making flash remoting components for ColdFusion. We should have known better.

Thank you everyone. My first 48 hours of CF have been very warm and welcoming. @Mark Takata (Adobe) was kind enough to call us and politely emphasize the obvious security issues of being 4 years out of security support. We're looking to engage some outside help (waiting for 2 level up approval) We're waiting on .edu / hospital pricing for CF2023 licenses. CommandBox is pretty close to the top of the list. (understanding the existing setup slightly higher for me) @bdw429s , the oracle table was super helpful. Thank you. @*sknowlton* The cluster is pretty lightly loaded at this point. Most of the apps migrated to rails. We could probably get by with 1 copy of apache. FWIW, 7 years ago, the guys told management that it would be easier to migrate to rails than move from CF11 to CF2016 . I'm more inclined to believe what I heard Mark say (perhaps I heard what I wanted to hear) We can (mostly) "plop" our CF11 files into a CF2023 directory , fix some dates and go?

Rewriting in another language is ALWAYS going to be way more work. I've worked with many companies who bought that lie and years later were stuck on some ancient version of CF because they stopped upgrading.

Probably? I think since cf11, my app has run into 3 issues that required code changes • The date format changes that Mark mentioned • CF2018 started throwing errors when you use invalid cfsqltype values (which meant I suddenly knew about a whole bunch of bugs and had to fix them quickly) • CF2021 update 5(?) broke XmlTransform in the name of security, so I needed to add a jvm argument.

I'll tell you a tale of what happened to us... We decided to do a rewrite in CFML, from legacy .cfm code to modern CFC-based OOP/frameworks. We evaluated CF9 (in prerelease at the time) against Railo and decided to go with Railo (free, open source), but we also switched from Windows to Linux and IIS to Apache, and rewrote the system from the ground-up using ColdBox. It took 3 years and was a very painful launch (performance issues, mostly). Railo became Lucee and we switched with it. We started integrating another JVM language (b/c we were using it for other backend processes that CFML's HTTP-based request/response paradigm wasn't suited for). Lucee decided to implement OSGi, which broke our polyglot system so we got stuck on an old version -- and we still have one app stuck on that version. Which means one app stuck on JDK 8 (while everything else now runs on JDK 20 and is about to move to JDK 21). We built newer apps with FW/1 and then ultimately rewrote everything piecemeal in a hybrid CFML/other JVM language approach, which allowed us to do everything incrementally. It's hard to put a price on the incremental rewrite, but we couldn't do a lot of what we do today on CFML of any flavor: we have deployable apps that are self-contained and run directly on the JVM and are just 23-45MB in size, and mostly run in just 512MB of RAM. We still have one legacy app running Lucee 4.5 on CommandBox on JDK 8. We have to rewrite it in 2024 because JDK 8 will no longer be supported by the other JVM language we switched most code to. TL;DR: Lucee proved a dead-end to us. It was free but the project doesn't really care about backward compatibility. ColdBox also proved a dead-end to us -- but only because we had very specific multi-tenant, SSL/non-SSL requirements that ColdBox 3 didn't satisfy, so we customized it and that made it harder to upgrade. In addition, our environment was unusual enough that we ran into thread safety bugs all over the place and, in patching those, also made it harder to upgrade. Most people's needs are met by ColdBox out-of-the-box and upgrading is fine for them. If we'd been willing to pay for Adobe CF licenses, we'd have continued to upgrade and wouldn't have gotten stuck on an old CFML engine on an old JDK. Given that we migrated away from CFML, it's hard to analyze the costs (everything we use now is free, open source, and we can upgrade any component of it independently whenever we want). Bottom line: CommandBox is a great choice, no matter what else you do. Get yourself upgraded to ACF 2023 -- if your company is willing to pay license fees and/or support, it's a no-brainer to move off the old CF version (and the old JDK). Don't switch to Lucee just because it's free: either pay Adobe license fees and support or use that money to rewrite to another JVM language (NOT Ruby! NOT Python!) -- rewriting to another JVM language lets you do it incrementally and spread the cost over years.

A little late but @seancorfield very similar experiences but, for us we went with Kotlin and Spring Boot and haven't looked back.