Posted by
Perry Hiltz, Binary Tree Solutions Architect
When Enterprise organizations make the move from Domino messaging to Exchange messaging, more often than not, a number of Domino applications are left behind. Unfortunately, not all Domino Applications are easily moved over to other platforms and quite often the legacy Domino infrastructure is still distributed. There are challenges associated with centralizing these applications and updating the workstations at the client level.
Sure, Domino has built in tools that can do the moves for you, but these tools have limitations and issues. AdminP is a great tool, but it simply creates the replica and you still have to update the Administrative ACL and add the replica to cluster members. Then, to redirect the workstation, there’s an additional challenge. You must add a redirector to the old application and hope users access it in a timely manner. This does not, however, remove references to the old server icons.
Lastly, there’s the issue of server schedule agents. When developers build agents, the agents are typically set to run on a particular server. Depending upon the purpose of the agent, it may not be able to run on all servers. As a result, when you move your applications to a centralized server, you’re still left with the schedule agents’ changes. Finding them all becomes a challenge, and then determining which ones are set to run on servers is the next obstacle.
But there’s a solution that can help you address all of these issues …it’s called
Domino Consolidator.
READ MORE >>
As the year comes to a close, Binary Tree would like to share our Top 5 Blog Posts of 2012. The goals of our blog posts are to help educate and empower our customers and partners with the latest and most valuable information to ensure successful email migration projects.
1.) In February, the blog post Don’t Move Your Mailbox Data TWICE!!!, discusses the importance of doing your homework when selecting a specialized software tool to help you with a specific need, such as an email migration project. It might just save you and your users a lot of headaches in the long run, and save you a bunch of money too.
2.) John Alumbaugh wrote a guest blog post for us in June on Ensuring a Successful Migration to Office 365. At the time, John was Director of Consulting Services at CloudStrategies LLC. John has since joined Binary Tree and in this post he discusses lessons learned to ensure a streamlined and successful migration to Microsoft Office 365.
READ MORE >>
Posted by
Valentin Vasquez, Senior Solutions Architect, E2E Complete
Customer questions relating to Exchange resource forests are becoming more and more common for our technical team. Organizations want to consolidate their existing Exchange environments to a single Active Directory (AD) forest running
Exchange 2010, while leaving their user accounts in their old AD domains.
Merging multiple AD forests into a single forest is a
VERY complex undertaking, which requires transitioning workstations, laptops, servers, printers and all applications that interact within that AD environment. So it’s no wonder that customers shy away from that
migration project and go with a brand new build-out of an Exchange resource forest to run their messaging environment in a more centralized, consolidated infrastructure.
This may become an even more common method to deploy
Exchange 2013 when it is released. However, there are some serious challenges related to linking active user accounts from one AD environment to a separate Exchange AD forest and successfully migrating all the email data intact.
In this article, I’m going to discuss the different steps that MUST be performed to do this manually and describe how our E2E Complete software automates this entire process.
READ MORE >>
Everyone knows that the first step in any activity is the most crucial one. An email migration project is no exception. However, the importance of the proper project initiation is often overlooked. Many times a project kickoff meeting focuses only on the statement of work when it should include a full planning workshop, which involves significantly more than a document review. There are several key considerations that should be addressed during this session and all responsible parties must be in attendance. Binary Tree specializes in email migrations and we often run migration planning workshops with customers that are preparing for their transition to Exchange 2010. In this blog post, I’m going to impart some of our best practices to drive a successful planning workshop for an upcoming mail migration. The main topics covered in this article are: 
- Understand why the migration is occurring
- Define critical goals for the success of the project
- Identify project team roles and responsibilities
- Plan for end-user change management
- Ensure team buy-in on realistic project timeline and milestones
- Address the top 3 overlooked critical success factors
READ MORE >>
Binary Tree specializes in
email migrations and it is quite often that we attend planning workshops with customers that are preparing for their
transition to Exchange 2010. During these meetings, a very common question that comes up is,
“How fast can we migrate to the new environment?” And it may sound tongue-in-cheek but our standard answer to this question is,
“You can migrate as fast as you want.”
This usually comes as quite a shock to the project teams. However, as we explain the scalability of migration processing they come to understand that the theoretical limits for migration speeds are really only bound by the available bandwidth on their network and the speed of their servers. The more migration infrastructure (sessions and processing methods) you configure within your environment, the faster the data will get moved.
The true gating factor is the practical limitation of migrating end-users,
NOT their mailbox data. Moving mailbox data is easy, moving end-users is hard. The change management aspects of a migration project, which include end-user training, desktop updates/refresh, communications, migration scheduling, help-desk support, among other things, are truly the limiting factors for how fast you can migrate email to a new platform.
But customers always want to know how they can perform an accurate estimation of their data throughput for a migration to see what their theoretical limitations are for the project. There are two important factors that I’ll describe in this post which are key to crystalizing a migration throughput estimate:
- Identify and Validate a Single Migration Speed Unit (for each source and target location)
- Perform a Migration Test in the Production Environment with Real Mailbox Data