<h2>Introduction</h2>

 In this article, I’d love to share one of the most challenging yet
 rewarding projects I’ve worked on:
 migrating a Windows-based application that used
 SQL Anywhere database (connected via ODBC)
 to a Linux server on DigitalOcean.


 At first, I wasn’t even sure if this was possible! Moving a
 Windows GUI-based app, which depended on
 Windows-specific database drivers, to a
 headless Linux server seemed daunting.


 I took a research and development approach, solving one
 challenge at a time. In this post, I’ll walk you through the
 problems I faced, the solutions I implemented, and the lessons I
 learned. The final outcome? The application is now
 running on DigitalOcean, fully operational, and accessible via VNC
 Viewer!
 🎉


<h2>Project Overview</h2>

 The application was originally hosted on an
 IONOS Windows server and relied on:

<ul>
 <li>SQL Anywhere 9 as the database</li>
 <li>
 ODBC (Open Database Connectivity) for database
 communication
 </li>
 <li>Windows GUI for user interaction</li>
</ul>

 The goal was to migrate it to a
 Linux-based DigitalOcean server. However, there were
 many unknowns:

<ul>
 <li>Would ODBC work on Linux?</li>
 <li>Could SQL Anywhere be installed and run properly?</li>
 <li>
 Could I make a GUI-based Windows app work in a headless
 environment?
 </li>
</ul>

 I decided to experiment, test, and iterate until I found
 solutions.


<h2>Challenges, Solutions, and Learnings</h2>

<h3>1️⃣ Understanding and Configuring ODBC on Linux</h3>
🔴 Challenge:
<ul>
 <li>
 I had never worked with ODBC before and didn’t know how it
 worked.
 </li>
 <li>
 The app relied on ODBC drivers that were
 Windows-specific.
 </li>
</ul>
✅ Solution:
<ul>
 <li>
 Researched and realized
 ODBC is a middleware that allows database communication.
 </li>
 <li>
 Configured <code>odbcinst.ini</code> and <code>odbc.ini</code> inside
 Docker containers to replicate ODBC functionality on Linux.
 </li>
</ul>

 🎓 Learning: Now I understand
 how ODBC works and how to configure it on Linux for
 Windows-based applications.


<h3>2️⃣ Installing and Running SQL Anywhere on Linux</h3>
🔴 Challenge:
<ul>
 <li>SQL Anywhere does not have a native Linux installer.</li>
 <li>
 I needed to find a way to install it
 without breaking ODBC support.
 </li>
</ul>
✅ Solution:
<ul>
 <li>
 Extracted SQL Anywhere installation files from the
 Windows server.
 </li>
 <li>Copied them into a Docker container running Wine.</li>
 <li>
 Created a startup script (<code>db-entrypoint.sh</code>) to
 initialize and launch SQL Anywhere (<code>dbsrv9.exe</code>)
 inside Wine.
 </li>
</ul>

 🎓 Learning: Learned how to
 run SQL Anywhere inside a Docker container using Wine.


<h3>3️⃣ Running a Windows GUI App on a Linux Server</h3>
🔴 Challenge:
<ul>
 <li>
 The application had a graphical user interface (GUI).
 </li>
 <li>
 Linux servers are headless, so there was
 no display for GUI applications.
 </li>
</ul>
✅ Solution:
<ul>
 <li>Used Wine to run Windows applications on Linux.</li>
 <li>
 Installed Xvfb (X Virtual Frame Buffer) and
 x11vnc to create a virtual display.
 </li>
 <li>
 Used VNC Viewer to
 remotely access the GUI application running on the Linux
 server.
 </li>
</ul>

 🎓 Learning: Successfully
 accessed and interacted with the application remotely.


<h3>4️⃣ Installing and Configuring <code>odbcad32.exe</code></h3>
🔴 Challenge:
<ul>
 <li>
 <code>odbcad32.exe</code> (ODBC Administrator)
 was missing in the Wine installation.
 </li>
 <li>
 The application required specific ODBC drivers that were
 not installed by default.
 </li>
</ul>
✅ Solution:
<ul>
 <li>
 Installed MDAC28 and Jet40 via <code>winetricks</code>.
 </li>
 <li>
 Manually downloaded and
 copied missing DLLs (<code>dao350.dll</code>,
 <code>dao360.dll</code>).
 </li>
 <li>
 Used Wine registry (<code>regedit</code>) to manually
 configure ODBC settings.
 </li>
</ul>

<h3>5️⃣ Ensuring the Application Runs Automatically in Docker</h3>
🔴 Challenge:
<ul>
 <li>
 The app was not running automatically on container startup.
 </li>
</ul>
✅ Solution:
<ul>
 <li>
 Updated <code>entrypoint.sh</code> to
 keep the app running in the foreground.
 </li>
</ul>

<h2>The Final Result 🎉</h2>

 It took me just 4 days, thanks to my expertise in deployment, Docker, and
 Linux. I worked extremely hard, staying focused and determined. At times, I
 felt like giving up, but I pushed through—because this is the mindset every
 software developer needs when facing new and unfamiliar challenges. And now:

<ul>
 <li>
 ✅ Running on a DigitalOcean Linux server inside Docker.
 </li>
 <li>✅ SQL Anywhere 9 is working properly with ODBC.</li>
 <li>✅ GUI-based app is accessible via VNC Viewer.</li>
 <li>
 ✅ Fully automated and restarts on every container launch.
 </li>
</ul>

<h2>Final Takeaways</h2>
<ul>
 <li>
 ✅ ODBC is critical for Windows-to-Linux database
 migrations.
 </li>
 <li>
 ✅ SQL Anywhere can run on Linux via Wine, even without
 native support.
 </li>
 <li>
 ✅ GUI-based Windows apps can run on Linux using Xvfb and
 VNC Viewer.
 </li>
</ul>

<h2>Next Steps</h2>
<ul>
 <li>🚀 Automate deployment with a streamlined Docker Compose setup.</li>
 <li>
 🚀 Explore alternative solutions (e.g., Wine alternatives like Bottles,
 PlayOnLinux).
 </li>
</ul>

 This was an exciting deep dive into Windows-to-Linux migrations! Let me
 know if you have any questions or if you're tackling a similar challenge!
 🚀

This project involved migrating a Windows-based application that relied on SQL Anywhere and ODBC to a Linux server on DigitalOcean. Using Docker, Wine, Xvfb, and VNC Viewer, I successfully enabled the application to run in a headless Linux environment while maintaining full database connectivity. This post covers the key challenges, solutions, and technical learnings from this migration.

Migrating a Windows App to Linux – SQL Anywhere & ODBC

Migrating a Windows-Based Application to Linux on DigitalOcean

<h2>Introduction</h2>

 In this article, I’d love to share one of the most rewarding and
 challenging projects I’ve worked on:
 building an intelligent volunteer matching system. It was a journey filled
 with problem-solving, innovation, and a few surprises along the way. If you’ve
 ever been interested in building complex algorithms, handling real-time data,
 or making a tangible social impact through technology, this one’s for you!


<h2>Project Overview</h2>

 Imagine an organization that connects volunteers with charities in need. Now,
 picture the challenge of making sure every volunteer is matched with the right
 opportunity— considering their skills, interests, and availability.
 Sounds simple? Trust me, it wasn’t!


 My goal was to build a solution that could intelligently match volunteers with
 charity needs while ensuring that group dynamics, skill diversity, and
 real-time availability were factored into the equation. The challenge?
 Existing solutions were too basic, focusing only on one-to-one matches without
 considering the complexities of group-based volunteering.


 I had to build a robust algorithm capable of handling
 multiple variables and processing them in real-time to create meaningful,
 effective volunteer placements.


<h2>Problem Statement</h2>

 From the beginning, I knew this wasn’t going to be a straightforward problem.
 Traditional volunteer-matching solutions didn’t consider:

<ul>
 <li>
 Group dynamics – Matching multiple volunteers to a single
 opportunity.
 </li>
 <li>
 Skill variety – Ensuring teams had the right mix of
 abilities.
 </li>
 <li>
 Real-time availability – Avoiding mismatches due to
 scheduling conflicts.
 </li>
</ul>

 My manager made it clear:
 “We need a solution that works, scales, and delivers results without
 requiring constant manual intervention.”


<h2>Initial Solution Attempt</h2>

 My first attempt at solving this problem was based on traditional
 recommendation system techniques, specifically the
 dot product approach. I assigned numerical weights to
 volunteers' skills, interests, and availability and attempted to match them
 with charity needs using this technique.


 What happened?
 While the dot product method provided decent results for
 one-to-one matches, it completely broke down when trying to form
 volunteer groups. The algorithm didn’t account for group
 dynamics, skill balance, or how individuals with different abilities would
 work together.


 Example: Suppose we had 10 volunteers, and three charity
 projects required different combinations of skills. The dot product approach
 might assign five software developers to a project that only needed one, while
 leaving other necessary roles, such as marketing and logistics, unfilled.


<h2>Refining My Approach</h2>

 After reviewing the failures of my initial approach, I realized I needed a
 more intelligent way to structure volunteer groups. Instead of treating each
 volunteer as a separate entity, I focused on building a
 group-based matching system that could consider multiple
 factors at once.


<h3>Step 1: Implementing a Dynamic Weighting System</h3>

 Instead of assigning fixed weights to skills, I implemented a contextual
 scoring system where each skill was weighted dynamically based on the
 charity’s specific requirements rather than a global scale.


 I also introduced a mechanism that boosted complementary skills (e.g., project
 management + graphic design) to encourage diverse teams. This ensured that no
 team ended up with an imbalance of similar skills while lacking critical
 expertise.


 Example: If a project required leadership, communication, and
 technical skills, volunteers with those skills would receive a weighted boost
 in score when paired together.


<h3>Step 2: Introducing a Group Compatibility Model</h3>

 I designed a compatibility function that evaluated team structures instead of
 just individual scores. This function:

<ul>
 <li>
 Ensured each team had at least one volunteer in each required skill
 category.
 </li>
 <li>
 Penalized teams where volunteers had overlapping skill sets without required
 complementary skills.
 </li>
 <li>
 Considered collaboration scores derived from previous volunteer teamwork
 history (if available).
 </li>
</ul>

 Example: If a food distribution project required logistics
 planning, customer engagement, and coordination, the system ensured the final
 team had at least one volunteer with each skill rather than assigning three
 logistics planners.


<h3>Step 3: Shifting to a Team-Based Evaluation System</h3>

 Instead of sorting volunteers by highest individual scores, I restructured the
 algorithm to rank teams as a whole. This new approach used a
 constraint-solving method (inspired by Knapsack Optimization) to maximize:

<ul>
 <li>Skill coverage across the team.</li>
 <li>Diversity in experience levels.</li>
 <li>Scheduling feasibility.</li>
</ul>

 Example: If an event required volunteers for planning,
 fundraising, and setup, the system ensured each team had at least one person
 covering these areas rather than selecting the highest-scoring individuals.


<h3>Step 4: Introducing an Iterative Optimization Process</h3>

 After running initial matches, I introduced an adaptive feedback loop where
 the system stored historical match performance and feedback from charities.
 The system then adjusted weight distributions over time based on match success
 rates.


 If a team failed to meet the needs of a charity, future matches penalized
 similar configurations to avoid repeated mistakes. This allowed the algorithm
 to refine itself dynamically and improve over time.


<h2>Final Solution & Results</h2>
With my refined approach, the volunteer matching system was able to:
<ul>
 <li>
 Significantly improve match accuracy by forming
 well-balanced teams.
 </li>
 <li>
 Handle real-time updates to adjust matches as volunteer
 availability changed.
 </li>
 <li>
 Scale efficiently as the number of volunteers and charities
 increased.
 </li>
</ul>

 The result? A highly efficient and scalable volunteer matching system that
 successfully connected volunteers with the right opportunities while ensuring
 well-formed, productive teams.


<h2>Final Thoughts & Takeaways</h2>

 This project taught me a ton about algorithm design, system optimization, and
 balancing scalability with cost efficiency. Here are my key takeaways:

<ul>
 <li>
 One-size-fits-all solutions don’t work – Customization is
 key when dealing with complex, real-world problems.
 </li>
 <li>
 Scalability matters – A robust algorithm ensures a system
 can grow without breaking.
 </li>
 <li>
 Data-driven decision making – The more relevant data you
 use, the better the matches.
 </li>
</ul>

 The system I built is still running successfully today, helping volunteers
 find the best opportunities with minimal hassle.

I’d love to hear your thoughts!

This project involved designing a volunteer matching system that intelligently connects volunteers with charitable opportunities by factoring in group dynamics, skill compatibility, and real-time availability. By developing a custom matching algorithm, we solved scalability and accuracy challenges, creating a seamless experience for both volunteers and organizations.

Intelligent Volunteer Matching: A Data-Driven Approach | Tech Tips by Moh

Intelligent Volunteer Matching: A Data-Driven Approach

<h2>Introduction</h2>

 In this article, I'd like to share one of the most
 exciting and challenging projects I’ve worked on:
 migrating a complex WordPress website to a modern
 Next.js and Django web app.


 I’ll walk you through the key problems we faced, the
 solutions we crafted, and the outcomes. So,
 if you’re interested in scaling web applications,
 improving SEO, and
 modernizing legacy systems, this is for you!


<h2>Project Overview</h2>

 It's common for most startups working on a
 growing platform to realize at some point that the
 tech stack initially adopted to launch the business is no
 longer working efficiently and is struggling to keep up. That’s precisely what
 happened in our case.


 Our platform was thriving, handling
 dynamic content, integrating APIs, and
 supporting an expanding user base. But behind the scenes?
 WordPress was reaching its limits. The backend was
 overburdened, API management was becoming a
 headache, and scalability was becoming a
 genuine concern.


<h2>Problem Statement</h2>
My manager approached me one day with a clear goal:
<blockquote>
 We require an automated system that seamlessly integrates
 some existing features from our app with the website. Our
 current WordPress setup is becoming a bottleneck.
</blockquote>

 At first, it seemed pretty time-consuming, and my manager was worried about
 the timeline needed to complete this project. The existing
 WordPress platform had deep
 customizations and a
 rigid database structure. Furthermore,
 SEO optimizations were critical for the business. The
 challenge was ensuring all these elements were
 preserved or improved while transitioning to a more
 scalable and modern solution.


<h2>Key Reasons for the Migration</h2>
<ul>
 <li>
 Performance Issues: The
 WordPress backend was struggling under
 heavy traffic.
 </li>
 <li>
 Scalability Concerns: The website was growing, and
 WordPress wasn’t handling the increasing complexity well.
 </li>
 <li>
 Integration Complexity: Managing APIs and
 external services with WordPress was
 cumbersome and inefficient.
 </li>
</ul>

<h2>Research and Planning</h2>

 After reviewing multiple options, I suggested migrating to
 Next.js instead of React (which was
 initially considered) due to its built-in SEO advantages and
 routing system, and Django for the backend,
 given its scalability and security.


<h2>Development Phases</h2>
<h3>1. Migrating a Highly Customized WordPress Database</h3>

 WordPress isn’t just a blogging platform—it’s a fully-fledged
 CMS with deep interdependencies between
 posts, pages, taxonomies, and metadata. Simply exporting the
 database and re-importing it wasn’t going to work.

Solution:
<ul>
 <li>
 Wrote custom scripts to
 extract, transform, and load (ETL) the data into a new
 Django-compatible schema.
 </li>
 <li>
 Mapped WordPress custom post types,
 meta fields, and taxonomies to their
 Next.js equivalents.
 </li>
 <li>
 Ensured data integrity was maintained, avoiding
 broken relationships or missing content.
 </li>
</ul>

<h3>2. Handling Rich Text, Embedded HTML, and Styles</h3>

 WordPress content often includes
 custom HTML, CSS, and shortcodes, which can make it tricky to
 display correctly in a new environment.

Solution:
<ul>
 <li>
 Used page scraping techniques to capture the rendered
 HTML & CSS from the live WordPress site.
 </li>
 <li>
 Converted necessary styles into
 Next.js-compatible modular CSS and styled components.
 </li>
 <li>
 Parsed and transformed shortcodes & embedded media into
 Next.js-friendly elements.
 </li>
</ul>

<h2>The Results: A Faster, More Scalable, and SEO-Optimized Platform</h2>

 After weeks of development, testing, and iterations, we
 successfully launched the new Next.js & Django web app.


<h3>🚀 Key Improvements Achieved:</h3>
<ul>
 <li>
 Performance Boost: Page load times improved significantly,
 enhancing user experience.
 </li>
 <li>
 Better SEO: Maintained (and improved)
 search rankings through optimized rendering.
 </li>
 <li>
 Scalability: The platform could now handle increased
 traffic without slowdowns.
 </li>
 <li>
 Cleaner Codebase: Easier maintenance and expansion for
 future features.
 </li>
</ul>

<h2>Final Thoughts & Takeaways</h2>

 This project taught me some valuable lessons about
 modern web development and migrations:

<ul>
 <li>
 ✅ Understanding Data Before Migration – A structured
 data migration plan is essential.
 </li>
 <li>
 ✅ Balancing Automation & Manual Adjustments – While
 scripts handle bulk migration,
 manual tweaks are sometimes necessary.
 </li>
 <li>
 ✅ SEO is More Than Just Keywords –
 Performance, metadata, and redirects play a considerable
 role.
 </li>
 <li>
 ✅ Next.js & Django = A Powerful Combination – The best of
 both worlds for frontend speed and
 backend robustness.
 </li>
</ul>

This project involved migrating a WordPress-based platform to a modern Next.js and Django architecture, solving key issues related to performance, SEO, and scalability. The transition improved page load speeds, optimized API interactions, and maintained SEO rankings while ensuring a cleaner, more efficient codebase.

Tech Tips By Moh | WordPress to Next.js & Django – Performance, SEO, and Scalability

A WordPress to Next.js & Django Migration Story: SEO, Speed, Scalability

<h2>Introduction</h2>

 Here, I'd like to talk about one of my breakthrough projects.
 First, I'll discuss the main function of the app, then I'll share one of the
 biggest challenges we faced during the project and how I approached solving
 it. I highly recommend reading this article to the end; I’m sure you’ll gain
 valuable insights.


<h2>Project Overview</h2>

 It has happened many times to all of us in our work environment: a decision
 needed to be made, but it required employees’ input.
 How great would it be if employees could share their ideas
 anonymously?
 This way, employees could share their truest thoughts without worrying about
 being judged by others.


 You got the point! Our application was designed to help
 businesses run voting campaigns, allowing employees to share their feedback on
 specific topics. Each employee had their own dashboard in the app, where they
 could see the topic and voting options, with the ability to cast their vote.
 The interesting part was that after casting their vote, they could see the
 real-time results until the voting period ended. Once the voting ended,
 everyone was notified about the most selected option, allowing them to be
 aware of the decision that would be made.


<h2>Problem Statement</h2>

 One day, my manager called me and said that most of our business partners had
 requested a notification system for our app to:

<ul>
 <li>Notify employees when a new vote starts.</li>
 <li>
 Send reminders as the voting deadline approaches for those who haven’t
 voted yet.
 </li>
 <li>
 Inform everyone about the most selected option once the voting
 ends.
 </li>
</ul>

 Then, my manager added,
 "This feature could be a game-changer for our app. I'm confident that it
 will make our business partners very happy and give them more assurance that
 employees won’t forget to cast their votes or miss a voting
 opportunity."



 Since most of our business partners were active Slack users, after a long
 discussion and some back-and-forth, we finally decided to build a
 comprehensive notification system that could send messages via both
 email and Slack.


<h2>Research and Planning</h2>

 I immediately started my own research so I could provide my manager with a
 clear report covering the
 feasibility, challenges, timeline, and tools required for
 developing this feature. To make a long story short, we decided to use
 Sendinblue (Brevo) as our SMTP server. I
 also realized that Slack provides a great API, allowing us to
 access the Slack workspaces of our business partners using the
 OAuth2 methodology.


<h2>Development Phases</h2>

 I planned to break the development of this feature into
 three phases:

<h3>Phase 1:</h3>

 Preparing logical scripts to ensur that notifications are sent at a precise
 time to the correct user.

<h3>Phase 2:</h3>

 Building scripts/functions to send the appropriate reminders with predefined
 dynamic variables via both Slack and email.

<h3>Phase 3:</h3>

 Building the OAuth system, allowing businesses to integrate
 their Slack workspace with our application and associate a
 specific Slack channel to send our notifications in that
 channel.


<h2>Challenge We Faced</h2>

 After completing these three phases, everything was
 functional and working great until we reached a stage where
 the increasing number of
 business partners and employees caused
 significant CPU spikes. This led to some
 breaks in the functionality of our application.



 My manager promptly called me and asked me to
 investigate why the app was not working as expected. After a
 thorough investigation, I realized that our application was
 not capable enough to handle a large number of
 concurrent requests efficiently.


<h2>Finding a Solution</h2>

 I knew that my manager didn’t just want to hear the reasoning behind this
 issue; she wanted a solution. In my report, I suggested
 adding Celery as a task manager to our app. This way:

<ol>
 <li>
 Tasks could be queued and completed by another worker, significantly
 improving the app's functionality.
 </li>
 <li>
 We could manage scheduling tasks programmatically rather than relying on
 the server's cron jobs.
 This would give us
 more control over every aspect of the system.
 </li>
</ol>

 Implementing Celery worked perfectly for our app for the
 first two years. However, once the
 number of users exceeded our expectations, even
 Celery alone was no longer efficient, and our
 server again experienced CPU spikes.


<h2>Batching System Implementation</h2>

 This time, after talking with my manager, I proposed
 vertical or horizontal scaling of our servers as the
 fastest way to overcome the issue. However, like most
 startups that are cautious about spending, my manager refused
 this approach and wanted me to find another solution.


 To explore alternative solutions, I
 reviewed the scripts once more, conducted
 additional research, and eventually came up with an idea:
 implementing a batching system.

<ul>
 <li>Break them into smaller groups.</li>
 <li>Send notifications to one batch at a time.</li>
 <li>Introduce a short pause.</li>
 <li>Proceed to the next batch.</li>
</ul>

 This approach significantly reduced CPU load while
 maintaining efficiency. After implementing this solution,
 the application remained stable for a long time, and it’s still working
 effectively today.


<h2>Next Step?</h2>

 So, what are your thoughts? If we again face a break in our
 app, would you suggest:

<ul>
 <li>Vertical scaling?</li>
 <li>Horizontal scaling?</li>
 <li>Or do you have a more cost-effective approach?</li>
</ul>
I’d love to hear your insights!

The application was designed to enable businesses to run voting campaigns while allowing employees to share their feedback anonymously. As part of this project, I led the development of a scalable notification system using Sendinblue (Brevo), the Slack API, and OAuth2 to automate reminders and ensure no one forgets to cast their vote. I further implemented Celery as a task manager in combination with a batching system to optimize performance while solving key scalability challenges.

Challenging Projects & Lessons Learned

Migrating a Windows-Based Application to Linux on DigitalOcean

Intelligent Volunteer Matching: A Data-Driven Approach

A WordPress to Next.js & Django Migration Story: SEO, Speed, Scalability

Scalable Notification System for Voting Apps with Email & Slack

Stay In Touch